在我工作的地方，sproc的最大优势是我们有更少的代码移植到VB。NET(来自VB6)。而且它的代码更少，因为我们对所有的查询都使用了spprocs。

当我们需要更新查询而不是更新VB代码，重新编译并在所有计算机上重新安装它时，它也有很大的帮助。

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

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

(Pseudocode)

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

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

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

这样想

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

我更喜欢存储过程

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

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

这只是我的小意思

我更喜欢使用O/R映射器，如LLBLGen Pro。

它为您提供了相对轻松的数据库可移植性，允许您使用强类型对象用与应用程序相同的语言编写数据库访问代码，并且在我看来，允许您更灵活地处理所拉回的数据。

实际上，能够使用强类型对象是使用O/R Mapper的充分理由。

存储过程的优点:

更容易检查代码。

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

更容易调谐。

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

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

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

缺点:

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

坚定地站在“存储过程不利于CRUD/业务逻辑使用”的阵营。我了解在报告、数据导入等方面的需求

写在这里…