何时使用存储过程而不是使用任何带有编程逻辑的 ORM？答案

【问题标题】：When to use Stored Procedures instead of using any ORM with programming logic?何时使用存储过程而不是使用任何带有编程逻辑的 ORM？
【发布时间】：2010-05-17 15:20:45
【问题描述】：

大家好，我想知道什么时候我应该更喜欢编写存储过程而不是编写编程逻辑和使用 ORM 或其他东西提取数据。

【问题讨论】：

标签： c# sql-server stored-procedures orm preferences

【解决方案1】：

存储过程在服务器端执行。

这意味着处理大量数据不需要通过网络连接传递这些数据。

此外，通过存储过程，您可以构建一致的复杂业务逻辑。

比如说，每次插入一笔交易都需要更新账户余额，而且需要一次插入很多笔交易。

您可以通过输入传递一个表变量或临时表，并在程序。这样会更有效率。

【讨论】：

+1 以获得经常被忽视（或未提及）的深刻见解。
@Joel：并非所有引擎都支持表变量。
你从来没有想过在触发器上使用它......我猜其中一件事......在数据库端有逻辑意味着你可以重用任何其他平台或语言......但是你你的回答总结得很好..

【解决方案2】：

我更喜欢 SP 而不是编程逻辑，主要有两个原因

性能，任何会减少结果集或可以在服务器上更有效地完成的事情，例如：
- 分页
- 过滤
- 排序（在索引列上）
安全性 -- 如果有人获得了应用程序对数据库的访问权限并想要清除您的所有记录，那么必须为每个记录执行 Row_Delete 而不是 DELETE FROM Rows 听起来不错。

【讨论】：

分页/过滤/排序仍将在任何值得其盐的 OR/M 中在服务器端完成。

【解决方案3】：

除非您发现性能问题，否则永远不要。（主要是意见）

（杰夫的一篇博文！） http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

如果您将存储过程视为优化： http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

【讨论】：

在过去，性能是一个问题，这就是为什么这个论点经常出现。今天，大多数嵌入式 sql 的运行速度与存储过程一样快。无论如何，使用 procs 还有很多其他原因。
这个话题就像堕胎或同性婚姻，争论不赢。不过，我会说，我个人使用存储过程的唯一一次是当我的老板强迫我反对我更好的判断或存在生产性能问题时。
我喜欢这句话：“应将存储过程视为数据库汇编语言：仅用于性能最关键的情况”
在决定不使用它之前，我实际上将该引用粘贴到评论中。绝对是一个很好的类比。
我还应该补充一点，ORM 处理大量更新可能很麻烦 - 这可能不会长期成为问题，但它是使用存储过程的一个令人信服的理由（一批更新语句不如一个更新/where 语句）。尽管如此，这些情况中的大多数可能都可以由 DBA 一次性处理，而不是在代码中处理。

【解决方案4】：

适当时。

复杂的数据验证/检查逻辑
避免多次往返以在数据库中执行一项操作
几个客户
任何应该基于的设置

你不能说“从不”或“总是”。

在某些情况下，数据库引擎的寿命会比您的客户端代码长。我敢打赌，数据库引擎升级/重构正在进行更多的 DAL 或 ORM 升级/重构。

最后，为什么我不能将代码封装在存储过程中？这不是好事吗？

【讨论】：

【解决方案5】：

与以往一样，您决定使用哪个将取决于您的应用程序及其环境。

这里有几种思想流派，这场辩论总是引起双方强烈的情绪。

存储过程（以及 Quassnoi 提到的大数据移动）的优点是逻辑被绑定在数据库中，因此可能更安全。它也只在一个地方。

但是，有些人认为应用程序逻辑的位置应该在应用程序中，特别是如果您计划访问其他类型的数据库（您必须经常为此编写不同的 SP）。

另一个考虑因素可能是实现应用程序所需的资源技能。

【讨论】：

【解决方案6】：

存储过程比 ORM 更可取的点是您有多个应用程序与同一个数据库通信的点。此时，您希望将查询逻辑嵌入到一个地方，而不是每个应用程序一次。即使在这里，您也可能更喜欢服务层（可以水平扩展）而不是数据库（只能垂直扩展）。

【讨论】：

操作得当，数据库可以（垂直）横向扩展就好了。
@Chris - 添加额外的应用服务器比添加托管 same 数据库的额外数据库服务器要容易得多。诚然，那么大是那些“好”的问题之一。