我不喜欢存储过程

存储过程更具维护性，因为：*每当您想更改某些SQL时，您都不必重新编译C＃应用程序

无论如何，当数据类型改变，或者想要返回额外的列或其他内容时，最终还是要重新编译它。总体上，您可以从应用程序下方“透明地”更改SQL的次数很小

• 您最终将重用SQL代码。
  

包括C＃在内的编程语言具有令人惊奇的东西，称为函数。这意味着您可以从多个位置调用同一代码块！惊人！然后，您可以将可重用的SQL代码放在其中之一中，或者，如果您想获得真正的高科技，则可以使用为您提供帮助的库。我相信它们被称为“对象关系映射器”，并且如今非常普遍。

尝试构建可维护的应用程序时，代码重复是最糟糕的事情！

同意，这就是为什么storedprocs是一件坏事的原因。与将代码重构为SQL块相比，将代码重构和分解（分解为较小的部分）要容易得多。

您有4个Web服务器和一堆使用相同SQL代码的Windows应用程序现在您意识到SQl代码有一个小问题，所以您宁愿......将proc更改为1或将代码推送到所有网络服务器上，在所有窗口框上重新安装所有桌面应用程序（单击可能会有所帮助）

为什么Windows应用程序直接连接到中央数据库？这似乎是一个巨大的安全漏洞，成为瓶颈，因为它排除了服务器端缓存。他们不应该通过Web服务或类似的Web服务器进行连接吗？

那么，推送1个新的proc还是4个新的Web服务器？

在这种情况下，推送一个新的存储 过程
比较容易，但是根据我的经验，95％的“推送更改”影响代码而不是数据库。如果您要在当月向Web服务器推送20项内容，向数据库推送1项内容，那么如果您将21件事推送至Web服务器，将零值推送至数据库，则几乎不会损失太多。

代码审查更容易。

你能解释一下吗？我不明白 特别要注意的是，这些存储程序可能不在源代码控制中，因此无法通过基于Web的SCM浏览器等进行访问。

更多缺点：

Storedprocs存在于数据库中，该数据库在外界看来像一个黑匣子。想要将它们放入源代码控制之类的简单事情变成了噩梦。

还有纯粹的问题。如果您想向CEO证明为什么要花700万美元建立一些论坛，那么将所有内容分解为一百万层可能是有意义的，但否则，为每件小事创建一个storageproc就是无用的驴子工作。效益。