在某些情况下，在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch)，它必须非常灵活，因此具有许多参数，非常复杂，那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说，这只是将一些处理从SQL转移到web服务器，但总的来说，这是一件好事。

这种技术的另一个优点是，如果你在SQL分析器中查找，你可以看到你生成的查询，调试它比看到一个存储的带有20个参数的proc调用要容易得多。

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

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

(Pseudocode)

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

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

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

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

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

in Code的优点: 更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植

实际上，我觉得你搞反了。恕我直言，在代码中维护SQL是痛苦的，因为:

你最终会在相关的代码块中重复自己 许多IDE不支持SQL作为一种语言，因此您只有一系列未出错的检查字符串来执行任务 数据类型、表名或约束的更改远比将整个数据库交换为一个新的数据库普遍得多 随着查询复杂性的增加，您的难度级别也在增加 测试内联查询需要构建项目

把Stored Procs看作你从数据库对象中调用的方法——它们更容易重用，只有一个地方可以编辑，而且如果你确实更改了数据库提供程序，更改发生在你的Stored Procs中，而不是在你的代码中。

也就是说，存储过程的性能增益是最小的，正如Stu在我之前说过的，你不能在存储过程中设置断点(目前)。

SQL注入攻击呈上升趋势。有人很容易找到这些代码并在你的网站上运行注入攻击。您必须始终始终将查询参数化。最好不要在动态SQL查询上运行exec(@x)。在我看来，使用内联SQL并不是一个好主意。

有些人认为，存储过程很麻烦，因为它们是另一组需要与代码分开维护的项。但是它们是可重用的，如果你在查询中发现了一个错误，你可以在不重新编译的情况下修复它们。

存储过程的优先级，因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好，代码更改通常只在SP端)。 -更好地进行性能调优

缺点:WHERE子句在使用条件上有很大的变化，需要高性能。