问与代码相比，将SQL保留在存储过程中的利弊是什么

EN

我不是存储过程的粉丝。

存储过程更易于维护，因为：*当您想要更改某些C#时，不必重新编译您的SQL应用程序

当数据类型改变时，或者您想要返回额外的列，或者其他任何情况时，您最终都会重新编译它。总的来说，你可以从你的应用程序下面“透明地”改变SQL的次数是相当少的

• 你最终会重用SQL代码。

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

当您试图构建一个可维护的应用程序时，

代码重复是您能做的最糟糕的事情！

同意，这就是为什么storedprocs是一件坏事。重构和分解(分解成更小的部分)代码到函数中要比将SQL分解到...SQL块？

您有4个with服务器和一堆windows应用程序，它们使用相同的SQL代码，现在您意识到SQl代码有一个小问题，所以您宁愿......在一个地方更改进程或将代码推送到所有all服务器，在所有windows系统上重新安装所有桌面应用程序(clickonce可能会有所帮助

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

那么，推送1个新的存储过程，还是4个新的new服务器？

在这种情况下，推送一个新的存储过程会更容易，但根据我的经验，95%的“推送更改”会影响代码，而不是数据库。如果你当月将20件事推送到zero服务器，将1件事推送到数据库，那么如果你将21件事推送到zero服务器，而将零件事推送到数据库，那么你几乎不会损失太多。

更容易进行代码审查。

你能解释一下是怎么做到的吗？我不明白这个。特别是考虑到sprocs可能不在源代码控制中，因此无法通过基于web的SCM浏览器等访问。

更多缺点：

Storedprocs存在于数据库中，在外界看来，它就像一个黑盒。像想要把它们放在源代码管理中这样简单的事情变成了噩梦。

还有一个纯粹的努力的问题。如果你试图向你的首席执行官证明为什么他们只花了700万美元就建立了一些论坛，那么把所有东西都分解成一个million tiers可能是有意义的，否则，为每一个小东西创建一个storedproc只是一项额外的徒劳工作，没有任何好处。

这是目前正在讨论的其他几个线程。我是存储过程的始终如一的支持者，尽管已经提出了一些关于Linq to Sql的很好的论点。

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

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

编辑此处是另一个current discussion

在我看来，你不能在这个问题上投赞成票或反对票。这完全取决于你的应用程序的设计。

我完全反对在3层环境中使用SP，在这种环境中，您前面有一台应用程序服务器。在这种环境中，您的应用程序服务器运行您的业务逻辑。如果您另外使用了SP，那么您将开始在整个系统中分发您的业务逻辑的实现，并且将变得非常不清楚谁负责什么。最终，您将得到一个应用程序服务器，它基本上只会执行以下操作：

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

最后，您的中间层在这个非常酷的4服务器集群上运行，每个集群都配备了16个CPU，而它实际上什么也做不了！多浪费呀!

如果你有一个胖的gui客户端，可以直接连接到你的数据库或者更多的应用程序，那就完全不同了。在这种情况下，SP可以充当某种伪中间层，将应用程序与数据模型解耦，并提供可控制的访问。