我更喜欢把它们保存在代码中(使用ORM，而不是内联或特别)，这样它们就可以被源代码控制覆盖，而不必保存.sql文件。

此外，存储过程本身并不更安全。使用sproc可以像使用内联一样轻松地编写糟糕的查询。参数化内联查询与sproc一样安全。

Definitely easier to maintain if you put it in a stored procedure. If there's difficult logic involved that will potentially change in the future it is definitely a good idea to put it in the database when you have multiple clients connecting. For example I'm working on an application right now that has an end user web interface and an administrative desktop application, both of which share a database (obviously) and I'm trying to keep as much logic on the database as possible. This is a perfect example of the DRY principle.

我参加的Microsoft TechEd安全会议的建议之一是，通过存储过程进行所有调用，并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做，但如果您已经在使用存储过程，那么这样做也无妨。

存储过程的优点 1).提高安全性，因为存储过程中的SQL本质上是静态的(大多数)。这将防止SQL注入。 2)。可重用性。如果需要为多个应用程序/组件返回相同的数据，这可能是一个更好的选择，而不是重复SQL语句。 3).减少客户端与数据库服务器之间的调用。

我不确定其他数据库，但您可以在大型机上的db2中使用主机语言创建存储过程，这使得它们非常强大。

我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。

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

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

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

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

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

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