坚定地站在“存储过程不利于CRUD/业务逻辑使用”的阵营。我了解在报告、数据导入等方面的需求

写在这里…

我通常写OO代码。我猜你们大多数人可能也有同感。在这种上下文中，所有业务逻辑(包括SQL查询)都属于类定义，这在我看来是显而易见的。分割逻辑(部分驻留在对象模型中，部分驻留在数据库中)并不比将业务逻辑放到用户界面中更好。

关于存储过程的安全性优势，在前面的回答中已经说了很多。它们分为两大类:

1)限制直接访问数据。这在某些情况下确实很重要，当你遇到这样的情况时，存储过程几乎是你唯一的选择。然而，根据我的经验，这样的情况是例外而不是规则。

2) SQL injection/parametrized queries. This objection is a red herring. Inline SQL - even dynamically-generated inline SQL - can be just as fully parametrized as any stored proc and it can be done just as easily in any modern language worth its salt. There is no advantage either way here. ("Lazy developers might not bother with using parameters" is not a valid objection. If you have developers on your team who prefer to just concatenate user data into their SQL instead of using parameters, you first try to educate them, then you fire them if that doesn't work, just like you would with developers who have any other bad, demonstrably detrimental habit.)

在某些情况下，在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch)，它必须非常灵活，因此具有许多参数，非常复杂，那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说，这只是将一些处理从SQL转移到web服务器，但总的来说，这是一件好事。

这种技术的另一个优点是，如果你在SQL分析器中查找，你可以看到你生成的查询，调试它比看到一个存储的带有20个参数的proc调用要容易得多。

对于Microsoft SQL Server，您应该尽可能使用存储过程来帮助执行计划缓存和重用。为什么要优化计划重用?因为生成执行计划的成本相当高。

Although the caching and reuse of execution plans for ad-hoc queries has improved significantly in later editions of SQL server (especially 2005 and 2008) there are still far fewer issues with plan reuse when dealing with stored procedures than there are for ad-hoc queries. For example, SQL server will only re-use an execution plan if the plan text matches exactly - right down to comments and white space, for example, if each of the following lines of SQL were to be executed independently, none of them would use the same execution plan:

SELECT MyColumn FROM MyTable WHERE id = @id
select MyColumn from MyTable WHERE id = @id
SELECT MyColumn  FROM MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id -- "some comment"
SELECT MyColumn FROM MyTable WHERE id = @id -- "some other comment"

除此之外,如果你不显式地指定类型的参数然后有一个好的机会,SQL Server可能出错,例如如果您执行上面的查询与输入4,然后用@ id查询SQL Server将parametrise SMALLINT(或可能是一个非常小的整数),所以如果你然后执行相同的查询@ id的说4000,SQL Server将parametrise INT,而不会重用相同的缓存。

我认为还有其他一些问题，老实说，大多数问题都可以解决——特别是在SQL Server的后续版本中，但是存储过程通常会提供更多的控制。

存储过程比代码更容易在数据库和源代码控制系统之间失去同步。应用程序代码也可以，但当您进行持续集成时，这种可能性较小。

数据库就是这样，人们不可避免地对生产数据库进行更改，只是为了暂时摆脱困境。然后忘记在环境和源代码控制系统之间同步它。生产数据库迟早会成为事实上的记录，而不是源代码控制系统——您将陷入无法删除任何scprocs的情况，因为您不知道它是否正在被使用。

一个好的过程应该只允许通过适当的渠道对产品进行更改，这样您就能够从源代码控制系统(无数据)从头开始重新构建数据库。但我只是说，因为它可以完成，也确实完成了——在最激烈的时刻，在大喊大叫的客户的电话之间，在紧盯着你的经理的电话之间，等等，对生产数据库进行了更改。

使用存储过程运行特别查询很尴尬——使用动态sql(或ORM)更容易，这可能是我自己使用存储过程的最大缺点。

另一方面，存储过程在你做出更改但不需要重新部署应用程序代码的情况下很好。它还允许您在通过网络发送数据之前对数据进行塑形，而代码中的sql可能必须进行多次调用来检索而不是塑形(尽管现在有方法可以在一次“调用”中运行多个sql语句并返回多个结果集，如ADO.NET中的MARS)，这可能会导致更多的数据通过网络传输。

不过，我不相信任何关于性能和安全性的争论。两者都有可能是好的，也有可能是坏的，而且同样可控。

在我工作的地方，sproc的最大优势是我们有更少的代码移植到VB。NET(来自VB6)。而且它的代码更少，因为我们对所有的查询都使用了spprocs。

当我们需要更新查询而不是更新VB代码，重新编译并在所有计算机上重新安装它时，它也有很大的帮助。