很明显，使用存储过程比在代码中构造SQL有几个优点。

代码实现和SQL变得彼此独立。 代码更容易阅读。 写一次用多次。 修改一次 不需要向程序员提供关于数据库的内部细节。等等，等等。

目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者，尽管有一些很好的论据支持Linq to Sql。

在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式，这意味着DBA可以自由地更改过程中的数据模型和代码，只要存储过程的输入和输出所表示的契约得到维护。

当查询隐藏在代码中，而不是在一个易于管理的中心位置时，调优生产数据库可能会非常困难。

这里是另一个当前的讨论

我不喜欢存储过程

存储过程更易于维护，因为: 你不需要重新编译你的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。

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

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

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

存储过程的优先级，因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好，代码更改通常只在SP端)。 -更好地进行性能调优

缺点:WHERE子句在使用条件上有很大的变化，需要高性能。