我喜欢存储过程，不知道有多少次我能够使用存储过程对应用程序进行更改，而不会对应用程序产生任何停机时间。

作为Transact SQL的忠实粉丝，调优大型查询已被证明对我非常有用。我已经6年没有写过任何内联SQL了!

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

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

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

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

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

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

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

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

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

我在其他答案中没有发现的一点是:

如果在您的环境中，数据库及其模式是体系结构的核心，应用程序的作用更小，那么更多地使用存储过程可能是有意义的，这可能有助于为所有需要访问DB的应用程序提供一个级别基础，从而减少代码重复(例如，您确定所有访问DB的应用程序都是用c#或其他。net语言编写的吗?)

另一方面，如果应用程序具有更核心的角色，而DB更多地充当应用程序的备份存储，那么减少存储过程的使用并通过提供一个公共持久性层(可能基于ORM工具/框架)来减少代码重复可能是明智的。

在这两种情况下，重要的是不要将DB视为存储过程的方便存储库。将它们保存在版本控制系统的源文件中，并尽可能地尝试自动化它们的部署(这实际上对所有与模式相关的构件都有效)。

SQL注入攻击呈上升趋势。有人很容易找到这些代码并在你的网站上运行注入攻击。您必须始终始终将查询参数化。最好不要在动态SQL查询上运行exec(@x)。在我看来，使用内联SQL并不是一个好主意。

有些人认为，存储过程很麻烦，因为它们是另一组需要与代码分开维护的项。但是它们是可重用的，如果你在查询中发现了一个错误，你可以在不重新编译的情况下修复它们。

在安全性方面，存储过程要安全得多。一些人认为，无论如何，所有的访问都将通过应用程序进行。许多人忘记了一件事，即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?

此外，正如MatthieuF所指出的，由于应用程序(无论是在桌面服务器还是web服务器上)和数据库服务器之间的往返次数减少，性能可以得到很大的提高。

In my experience the abstraction of the data model through stored procedures also vastly improves maintainability. As someone who has had to maintain many databases in the past, it's such a relief when confronted with a required model change to be able to simply change a stored procedure or two and have the change be completely transparent to ALL outside applications. Many times your application isn't the only one pointed at a database - there are other applications, reporting solutions, etc. so tracking down all of those affected points can be a hassle with open access to the tables.

我还将在加分栏中加上检查，以使SQL编程掌握在专门的人员手中，并使sp更容易隔离和测试/优化代码。

我看到的一个缺点是，许多语言不允许传递表参数，因此传递未知的数据值可能很烦人，一些语言仍然无法处理从单个存储过程中检索多个结果集(尽管后者在这方面并不使sp比内联SQL差)。