Definitely easier to maintain if you put it in a stored procedure. If there's difficult logic involved that will potentially change in the future it is definitely a good idea to put it in the database when you have multiple clients connecting. For example I'm working on an application right now that has an end user web interface and an administrative desktop application, both of which share a database (obviously) and I'm trying to keep as much logic on the database as possible. This is a perfect example of the DRY principle.

存储过程的优点:

更容易检查代码。

耦合更少，因此更容易测试。

更容易调谐。

从网络流量的角度来看，性能通常更好——如果您有一个游标或类似的东西，那么就不会多次访问数据库

您可以更容易地保护对数据的访问，删除对表的直接访问，通过procs加强安全性——这也允许您相对快速地找到更新表的任何代码。

如果涉及到其他服务(如Reporting服务)，您可能会发现将所有逻辑存储在存储过程中，而不是存储在代码中，并且必须复制它会更容易

缺点:

对开发人员来说更难管理的是:脚本的版本控制:每个人都有自己的数据库吗?版本控制系统是否与数据库和IDE集成在一起?

我不喜欢存储过程

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

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

这样想

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

我更喜欢存储过程

它也更容易做一个过程的性能测试，把它放在查询分析器 设置io/time on统计信息 设置showplan_text，瞧

不需要运行分析器来查看到底调用了什么

这只是我的小意思

在某些情况下，在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch)，它必须非常灵活，因此具有许多参数，非常复杂，那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说，这只是将一些处理从SQL转移到web服务器，但总的来说，这是一件好事。

这种技术的另一个优点是，如果你在SQL分析器中查找，你可以看到你生成的查询，调试它比看到一个存储的带有20个参数的proc调用要容易得多。