当存储过程被用于应用程序和数据库之间时，它们是最糟糕的。上面提到的使用它们的许多原因都可以由视图更好地处理。

有关安全的论点是站不住脚的。它只是将安全问题从应用程序转移到数据库。代码就是代码。我曾见过一些存储过程从应用程序中获取SQL，并使用它构建容易受到SQL注入攻击的查询。

一般来说，它们往往会在所谓的数据库开发人员和所谓的应用程序开发人员之间造成裂痕。实际上，所有编写的代码都是应用程序代码，只是执行上下文的不同。

使用丰富的SQL生成库，如LINQ, Rails ActiveRecord或Hibernate/NHibernate，使开发更快。在混合中插入存储过程会降低速度。

@Keith

安全?为什么scprocs会更安全?

正如Komradekatz所建议的，您可以禁止访问表(对于连接到DB的用户名/密码组合)，而只允许SP访问。这样，如果有人获得了数据库的用户名和密码，他们可以执行SP，但不能访问表或数据库的任何其他部分。

(当然，执行scproc可以给他们所有他们需要的数据，但这将取决于可用的scproc。给他们访问表的权限，他们就能访问所有东西。)

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

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

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

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

我更喜欢使用O/R映射器，如LLBLGen Pro。

它为您提供了相对轻松的数据库可移植性，允许您使用强类型对象用与应用程序相同的语言编写数据库访问代码，并且在我看来，允许您更灵活地处理所拉回的数据。

实际上，能够使用强类型对象是使用O/R Mapper的充分理由。

程序员希望代码在他们的应用程序中，DBA希望它在数据库中。

如果你两者都有，你可以通过使用存储过程在两者之间分配工作，程序员不必担心所有这些表如何连接在一起等(对不起，我知道你想控制一切。)

我们有一个第三方应用程序，它允许在数据库中的视图或存储过程上创建自定义报告。如果我把代码中的所有逻辑都放在另一个应用程序中，就不能重用它。如果你使用数据库编写所有的应用程序，这不是问题。

我还没有找到一种在源代码控制中轻松维护存储过程的好方法，使其与代码库一样无缝。这是不会发生的。仅这一点就使得在代码中添加SQL对我来说是值得的。在现代系统中，性能差异可以忽略不计。