目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者，尽管有一些很好的论据支持Linq to Sql。

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

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

这里是另一个当前的讨论

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

存储过程的更多优点:

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

你列出了2个procs的优点:

性能——不完全是。在Sql 2000或更高版本中，查询计划优化非常好，并被缓存。我相信甲骨文等公司也在做类似的事情。我不认为有什么理由再用scprocs来衡量业绩了。

安全?为什么scprocs会更安全?除非您有一个非常不安全的数据库，否则所有的访问都将来自dba或通过应用程序。总是参数化所有的查询-永远不要内联用户输入的东西，你会没事的。

无论如何，这是性能的最佳实践。

Linq绝对是我现在进行一个新项目的方式。请看这篇类似的文章。

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

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

我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。

这样想

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

我更喜欢存储过程

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

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

这只是我的小意思