存储过程纠纷

Question

可能重复： 在存储过程中保持SQL相对于代码的利弊是什么？

我正在听Hanselminutes播客“微型ORM的崛起”，其中一位客人( Saffron和Rob )概述了DBA坚持使用存储过程的经典原因：

1. 它们是预编译的，这使它们具有执行速度的优势。
2. 它们隐藏底层数据库方案，该方案允许将接口和实现分离开来，以防止脆性。

然后一位客人说这些不是很好的论据，并提出DBA坚持使用存储过程的真正原因是因为他们只是想保护自己不受中间层开发人员的忽视。

我觉得这个说法有点偏激。当然，我同意论点#2是有缺陷的，但我认为向数据库发送任意(未编译的) SQL是一个性能问题。有什么东西我错过了，可以解释为什么论点1不是真的？

我自己的答案，只是一个猜测，是有一个性能的成功--但这并不重要。这可能类似于一个开发人员试图优化他所写的每个循环，尽管只有1%的循环从调优中受益。我正确地捕捉了这个想法吗？

Answer 1

“但我认为，将任意(未编译的) SQL发送到数据库是一个很好的选择。”

从SQL6.5开始，存储的procs和其他有关预编译的sql语句之间的区别就不存在了。

存储过程和执行计划 在Server版本6.5和更早版本中，存储过程是部分预编译执行计划的一种方法。在创建存储过程时，部分编译的执行计划存储在系统表中。执行存储过程比执行SQL语句更有效，因为Server不必完全编译执行计划，只需完成对过程存储计划的优化。此外，存储过程的完全编译执行计划保留在Server过程缓存中，这意味着存储过程的后续执行可以使用预编译的执行计划。 Server 2000和SQLServerVersion7.0对语句处理进行了许多更改，这些更改将存储过程的许多性能优势扩展到所有SQL语句。 Server 2000和SQLServer7.0在创建存储过程时不会为存储过程保存部分编译的计划。存储过程是在执行时编译的，就像任何其他Transact-SQL语句一样。 Server 2000和SQLServer7.0为过程缓存中的所有语句保留执行计划，而不仅仅是存储过程执行计划。数据库引擎使用一种高效的算法来比较新的Transact-SQL语句和现有执行计划的Transact-SQL语句。如果数据库引擎确定新的Transact-SQL语句与现有执行计划的Transact-SQL语句匹配，则会重用该计划。这通过将执行计划重用扩展到所有SQL语句，从而降低预编译存储过程的相对性能优势。

http://msdn.microsoft.com/en-us/library/aa174792%28v=sql.80%29.aspx

Answer 2

根据我的经验，大多数DBA不能再写一个存储的proc，这样他们就可以驾驶航天飞机了。无论我在哪里工作，存储过程都是由应用程序开发人员编写的，他们还设计和实现了数据库。

话虽如此，存储过程并不比使用视图更快，如果没有经验的开发人员使用游标之类的东西编写，存储过程可能会慢一些。

Answer 3

至于性能:要么使用存储过程，要么使用预编译语句。

至于抽象:要么使用DAL/ORM，要么使用存储过程。

当然，存储过程可以做一些从外部和性能上都做不到的事情。所以和往常一样，这要看..。