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

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

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

我对存储过程的投票;作为接近数据的抽象层，集合高效，可被许多“客户端”(客户端语言)重用。T-SQL语言有点原始(我猜这是SO的大多数c#人都接触过的)，但Oracle的PL/SQL与任何现代编程语言不相上下。

至于版本控制，只需将存储过程代码放在版本控制下的文本文件中，然后运行脚本在数据库中创建procs。

CON

我发现在存储过程中进行大量的处理会使您的DB服务器在扩展您的行为时成为一个单一的不灵活点。

然而，如果您有多个服务器运行您的代码，那么在您的程序中进行所有这些处理而不是sql-server，可能会允许您进行更多的扩展。当然，这并不适用于只进行正常获取或更新的存储procs，而是适用于执行更多处理(如在数据集上循环)的存储procs。

PROS

Performance for what it may be worth (avoids query parsing by DB driver / plan recreation etc) Data manipulation is not embedded in the C/C++/C# code which means I have less low level code to look through. SQL is less verbose and easier to look through when listed separately. Due to the separation folks are able to find and reuse SQL code much easier. Its easier to change things when schema changes - you just have to give the same output to the code and it will work just fine Easier to port to a different database. I can list individual permissions on my stored procedures and control access at that level too. I can profile my data query/ persistence code separate from my data transformation code. I can implement changeable conditions in my stored procedure and it would be easy to customize at a customer site. It becomes easier to use some automated tools to convert my schema and statements together rather than when it is embedded inside my code where I would have to hunt them down. Ensuring best practices for data access is easier when you have all your data access code inside a single file - I can check for queries that access the non performant table or that which uses a higher level of serialization or select *'s in the code etc. It becomes easier to find schema changes / data manipulation logic changes when all of it is listed in one file. It becomes easier to do search and replace edits on SQL when they are in the same place e.g. change / add transaction isolation statements for all stored procs. I and the DBA guy find that having a separate SQL file is easier / convenient when the DBA has to review my SQL stuff. Lastly you don't have to worry about SQL injection attacks because some lazy member of your team did not use parametrized queries when using embedded sqls.

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

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

我不喜欢存储过程

存储过程更易于维护，因为: 你不需要重新编译你的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万个层可能是有意义的，但为每一件小事创建一个存储过程只是额外的无聊工作，没有任何好处。

@Keith

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

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

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