何时使用存储过程而不是将任何ORM与编程逻辑一起使用？
大家好我想知道什么时候我更喜欢编写存储过程来编写编程逻辑并使用ORM或其他东西来提取数据。
存储过程在服务器端执行。
这意味着处理大量数据不需要通过网络连接传递这些数据。
此外，使用存储过程，您可以构建一致的复杂业务逻辑。
比如，每次插入事务时都需要更新帐户余额，并且需要一次插入多个事务。
您可以使用输入传递表变量或临时表，并在过程中发出基于集合的SQL语句，而不是使用触发器（在许多系统中使用低效的逐个记录方法实现）。 这将更有效率。
我更喜欢SP而非编程逻辑主要有两个原因
- 性能，任何会减少结果集的东西，或者可以在服务器上更有效地完成，例如：
- 分页
- 滤波
- 排序（在索引列上）
- 安全性 – 如果某人有应用程序访问数据库并希望消除您的所有记录，则必须为每个记录执行
Row_Delete而不是DELETE FROM Rows已经听起来不错了。
除非您发现性能问题，否则永远不会 （主要是意见）
（杰夫博客文章！） http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
如果您将存储过程视为优化： http ： //en.wikipedia.org/wiki/Program_optimization#When_to_optimize
在适当的时候。
- 复杂的数据validation/检查逻辑
- 避免多次往返在DB中执行一个操作
- 几个客户
- 任何应该设置的东西
你不能说“永远”或“永远”。
还有一种情况是数据库引擎将比您的客户端代码更长。 我敢打赌，数据库引擎升级/重构还有更多的DAL或ORM升级/重构。
最后，为什么我不能在存储过程中封装代码？ 这不是一件好事吗？
与以往一样，您决定使用哪种产品取决于您的应用及其环境。
这里有几种思想流派，这场辩论总是引起双方强烈的感情。
存储过程的优势（以及Quassnoi提到的大数据移动）是逻辑被绑定在数据库中，因此可能更安全。 它也只在一个地方。
但是，还有其他人认为应用程序逻辑的位置应该在应用程序中，特别是如果您计划访问其他类型的日期记录库（您必须经常编写不同的SP）。
另一个考虑因素可能是您实施应用程序所需资源的技能。
存储过程变得优于ORM的点是您有多个应用程序与同一数据库通信的点。 此时，您希望将查询逻辑嵌入到一个位置，而不是每个应用程序嵌入一次。 即使在这里，您可能希望更喜欢服务层（可以水平扩展）而不是数据库（只能垂直扩展）。