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

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

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

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

我站在代码这一边。我们构建了所有应用程序(包括web和客户端)使用的数据访问层，所以从这个角度来看这是DRY。它简化了数据库部署，因为我们只需要确保表模式是正确的。它简化了代码维护，因为我们不需要查看源代码和数据库。

在与数据模型的紧密耦合方面，我没有遇到太多问题，因为我看不出哪里有可能真正打破这种耦合。应用程序及其数据在本质上是耦合的。

我不喜欢存储过程

存储过程更易于维护，因为: 你不需要重新编译你的c#应用每当你想改变一些SQL

无论如何，当数据类型发生变化时，或者您想返回一个额外的列时，您都将重新编译它。总的来说，你可以“透明”地从应用程序下面更改SQL的次数是非常少的

您最终会重用SQL代码。

编程语言，包括c#，都有这个神奇的东西，叫做函数。这意味着您可以从多个地方调用相同的代码块!神奇的!然后你可以把可重用的SQL代码放在其中一个，或者如果你想获得真正的高科技，你可以使用一个库来为你做这件事。我相信它们被称为对象关系映射器，现在很常见。

当您试图构建可维护的应用程序时，代码重复是最糟糕的事情!

同意，这就是为什么storedprocs是个坏东西。将代码重构和分解(分解成更小的部分)为函数要比将SQL分解成函数容易得多。SQL块?

你有4个web服务器和一堆使用相同SQL代码的windows应用程序，现在你意识到SQL代码有一个小问题，所以你宁愿......在一个地方改变程序或将代码推送到所有的web服务器，重新安装所有Windows盒子上的所有桌面应用程序(单击一次可能会有帮助)

为什么你的windows应用程序直接连接到中央数据库?这似乎是一个巨大的安全漏洞，因为它排除了服务器端缓存。他们不应该通过网络服务或者类似于你的网络服务器来连接吗?

所以，推出1个新的sproc，或4个新的web服务器?

在这种情况下，推送一个新的sproc更容易，但根据我的经验，95%的“推送更改”影响的是代码而不是数据库。如果那个月你向服务器推送了20个东西，向数据库推送了1个，那么如果你向服务器推送了21个东西，而向数据库推送了0个东西，你几乎不会损失太多。

更容易检查代码。

你能解释一下吗?我不明白。特别是考虑到scproc可能不在源代码控制中，因此不能通过基于web的SCM浏览器访问等等。

更多的缺点:

Storedprocs存在于数据库中，在外界看来，数据库是一个黑盒。简单的事情，比如想把它们放在源代码控制中，就变成了一场噩梦。

还有一个纯粹努力的问题。如果你想向你的CEO证明为什么只花了他们700万美元来建立一些论坛，那么把所有东西都分解成100万个层可能是有意义的，但为每一件小事创建一个存储过程只是额外的无聊工作，没有任何好处。

使用你的应用程序代码，因为它最擅长:处理逻辑。 使用数据库来做它最擅长的事情:存储数据。

您可以调试存储过程，但是您会发现在代码中调试和维护逻辑更容易。 通常，每次更改数据库模型时，都需要重新编译代码。

此外，具有可选搜索参数的存储过程是非常不有效的，因为您必须预先指定所有可能的参数，而复杂的搜索有时是不可能的，因为您无法预测一个参数将在搜索中重复出现多少次。

I'm firmly on the side of stored procs assuming you don't cheat and use dynamic SQL in the stored proc. First, using stored procs allows the dba to set permissions at the stored proc level and not the table level. This is critical not only to combating SQL injection attacts but towards preventing insiders from directly accessing the database and changing things. This is a way to help prevent fraud. No database that contains personal information (SSNs, Credit card numbers, etc) or that in anyway creates financial transactions should ever be accessed except through strored procedures. If you use any other method you are leaving your database wide open for individuals in the company to create fake financial transactions or steal data that can be used for identity theft.

存储的proc也比从应用程序发送的SQL更容易维护和性能调优。它们还允许dba查看数据库结构更改对数据访问方式的影响。我从未遇到过允许动态访问数据库的优秀dba。

in Code的优点: 更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植

实际上，我觉得你搞反了。恕我直言，在代码中维护SQL是痛苦的，因为:

你最终会在相关的代码块中重复自己 许多IDE不支持SQL作为一种语言，因此您只有一系列未出错的检查字符串来执行任务 数据类型、表名或约束的更改远比将整个数据库交换为一个新的数据库普遍得多 随着查询复杂性的增加，您的难度级别也在增加 测试内联查询需要构建项目

把Stored Procs看作你从数据库对象中调用的方法——它们更容易重用，只有一个地方可以编辑，而且如果你确实更改了数据库提供程序，更改发生在你的Stored Procs中，而不是在你的代码中。

也就是说，存储过程的性能增益是最小的，正如Stu在我之前说过的，你不能在存储过程中设置断点(目前)。