@Keith

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

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

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

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然，如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

存储过程。

如果出现错误或者逻辑稍有变化，您不必重新编译项目。此外，它允许从不同的来源访问，而不仅仅是在项目中编写查询的一个地方。

我不认为维护存储过程更难，你不应该直接在数据库中编写它们，而应该先在单独的文件中编写，然后你可以在任何你需要设置的DB上运行它们。

存储过程的优点 1).提高安全性，因为存储过程中的SQL本质上是静态的(大多数)。这将防止SQL注入。 2)。可重用性。如果需要为多个应用程序/组件返回相同的数据，这可能是一个更好的选择，而不是重复SQL语句。 3).减少客户端与数据库服务器之间的调用。

我不确定其他数据库，但您可以在大型机上的db2中使用主机语言创建存储过程，这使得它们非常强大。

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

我完全反对在三层环境中使用sp，在这种环境中，前端是应用服务器。在这种环境中，应用服务器用于运行业务逻辑。如果你额外使用sp，你就开始在整个系统中分配业务逻辑的实现，谁负责什么就会变得非常不清楚。最终你将得到一个基本上只会做以下事情的应用服务器:

(Pseudocode)

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

因此，最终你的中间层运行在这个非常酷的4个服务器集群上，每个服务器都配备了16个cpu，实际上它什么都不会做!太浪费了!

如果你有一个臃肿的gui客户端，直接连接到你的数据库或甚至更多的应用程序，这是一个不同的故事。在这种情况下，SPs可以充当某种伪中间层，将应用程序与数据模型解耦，并提供可控的访问。

我不喜欢存储过程

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