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

写在这里…

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然，如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

@Keith

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

存储过程提供了抵御SQL注入攻击的内在保护。

然而，您并没有完全受到保护，因为您仍然可以编写容易受到此类攻击的存储过程(即存储过程中的动态SQL)。

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

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

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

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

我非常支持代码而不是SPROC。第一个原因是保持代码紧密耦合，第二个原因是源代码控制的便利性，而不需要大量自定义实用程序。

在我们的DAL中，如果我们有非常复杂的SQL语句，我们通常将它们作为资源文件，并在需要时更新它们(这也可以是一个单独的程序集，并在每个db中交换，等等……)

这使得我们的代码和sql调用存储在同一个版本控制中，而不会“忘记”运行一些外部应用程序进行更新。

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

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

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