sql - 一直使用存储过程的缺点是什么？

Question

我读过一本关于 SQLServer 2008 的书。在这本书中，作者指出虽然存储过程主要是解决方案，但您应该避免一直使用它们。
我知道存储过程是预编译的，因此它们比普通命令运行得更快。也因为它们使用参数来传递数据，所以在 SQL 注入(inject)攻击的情况下，它们比普通的 SQL 命令安全得多。
所以我不明白的是:为什么不总是使用存储过程？

Answer 1

关于这个主题的一篇好文章

http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

所以我认为你应该做你喜欢的事。没有性能差异(对于您必须运行的查询的 msot)。

我想说不要存储过程:存储过程是一个痛苦的......:

无重载:如果要添加参数，则必须更新所有调用(或创建新 SP)

没有复杂类型:使用动态 sql，您可以根据复杂对象构建所有 sql 过滤器

安全不是原因:如果您的 sql 查询是 sql 注入(inject)证明并且您的数据库并非对所有人都可用，您可以在应用程序级别处理您的数据访问安全策略(任何 dba 都会杀了我这样说，但任何开发人员都会同意。 .. 我猜)

SP是“预编译”的(在第一次执行时，数据库服务器会为SQL服务器找到最佳执行计划)，但是在我们这个时代我们可以忘记它，“编译”时间真的很短所以我们没有'不必担心。我从来没有见过我认为“OMG 编译时间是我的应用程序瓶颈”的案例，大多数时候您的应用程序瓶颈将是查询本身，所以不必担心性能。

而这种“预编译”取决于您发送给 SP 的参数(在第一次调用时)，所以有时您可能会遇到很多 SP 的性能问题(称为“参数嗅探”)(参见此处:http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html)。