我不是存储过程的狂热爱好者，但我在一种情况下使用它们:

当查询相当大时，最好将其作为存储过程存储在数据库中，而不是从代码中发送。这样，就不会从应用服务器向数据库发送大量字符串字符，而只发送“EXEC SPNAME”命令。

当数据库服务器和web服务器不在同一个网络上(例如，internet通信)时，这是多余的。即使事实并非如此，太大的压力也意味着大量的带宽浪费。

但是，伙计，管理起来太糟糕了。我尽量避开他们。

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

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

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

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

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

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

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

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

这里是另一个当前的讨论

对于Microsoft SQL Server，您应该尽可能使用存储过程来帮助执行计划缓存和重用。为什么要优化计划重用?因为生成执行计划的成本相当高。

Although the caching and reuse of execution plans for ad-hoc queries has improved significantly in later editions of SQL server (especially 2005 and 2008) there are still far fewer issues with plan reuse when dealing with stored procedures than there are for ad-hoc queries. For example, SQL server will only re-use an execution plan if the plan text matches exactly - right down to comments and white space, for example, if each of the following lines of SQL were to be executed independently, none of them would use the same execution plan:

SELECT MyColumn FROM MyTable WHERE id = @id
select MyColumn from MyTable WHERE id = @id
SELECT MyColumn  FROM MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id -- "some comment"
SELECT MyColumn FROM MyTable WHERE id = @id -- "some other comment"

除此之外,如果你不显式地指定类型的参数然后有一个好的机会,SQL Server可能出错,例如如果您执行上面的查询与输入4,然后用@ id查询SQL Server将parametrise SMALLINT(或可能是一个非常小的整数),所以如果你然后执行相同的查询@ id的说4000,SQL Server将parametrise INT,而不会重用相同的缓存。

我认为还有其他一些问题，老实说，大多数问题都可以解决——特别是在SQL Server的后续版本中，但是存储过程通常会提供更多的控制。

存储过程的优点:

更容易检查代码。

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

更容易调谐。

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

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

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

缺点:

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