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

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

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

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

在安全性方面，存储过程要安全得多。一些人认为，无论如何，所有的访问都将通过应用程序进行。许多人忘记了一件事，即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?

此外，正如MatthieuF所指出的，由于应用程序(无论是在桌面服务器还是web服务器上)和数据库服务器之间的往返次数减少，性能可以得到很大的提高。

In my experience the abstraction of the data model through stored procedures also vastly improves maintainability. As someone who has had to maintain many databases in the past, it's such a relief when confronted with a required model change to be able to simply change a stored procedure or two and have the change be completely transparent to ALL outside applications. Many times your application isn't the only one pointed at a database - there are other applications, reporting solutions, etc. so tracking down all of those affected points can be a hassle with open access to the tables.

我还将在加分栏中加上检查，以使SQL编程掌握在专门的人员手中，并使sp更容易隔离和测试/优化代码。

我看到的一个缺点是，许多语言不允许传递表参数，因此传递未知的数据值可能很烦人，一些语言仍然无法处理从单个存储过程中检索多个结果集(尽管后者在这方面并不使sp比内联SQL差)。

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

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

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

这里是另一个当前的讨论

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

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

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

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

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

存储过程的优点:

更容易检查代码。

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

更容易调谐。

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

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

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

缺点:

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

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

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