存储过程或OR映射器？

Question

哪个更好？或者用SP和OR映射器？如果你已经有一个SP系统，是一个OR映射器值得吗？

Answer 1

我喜欢ORM，因为您不必重新发明轮子。这就是说，它完全取决于你的应用需求，开发风格和团队的风格。

这个问题已经覆盖Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 2

我个人发现，SP的性能往往更快，至少对于我定期执行的大数据项目来说。但我知道很多人用OR工具发誓并且不会做任何其他事情。

Answer 3

存储过程是更好的，在我看来，因为他们可以有从底层表中一个独立的安全配置。

这意味着您可以允许特定的操作，而不允许写入/读取特定的表。它还限制了人们在发现SQL注入漏洞时可以做的损害。

Answer 4

我认为使用OR映射器会增加应用程序源代码的可读性和可维护性，而使用SP将提高应用程序的性能。

Answer 5

存储过程传递。 OR映射器是语言特定的，并且经常会增加图形减速。

存储过程意味着您不受语言界面的限制，并且您只需以前向兼容的方式使用新的数据库接口即可。

我个人对OR Mappers的看法是，它们的存在凸显了流行的数据库结构中的设计缺陷。数据库开发人员应该认识到人们试图用复杂的OR-Mappers实现的任务，并创建服务器端实用程序来协助完成这项任务。

OR映射器也都是“漏抽象”综合征（Joel On Software: Leaky Abstractions）的史诗目标

如果它很容易找到的东西，因为不是心理的抽象层，它只是不能处理。

Answer 6

它们实际上并不相互排斥，尽管就你而言它们通常都是如此。

使用对象关系映射的优点是可以换出数据源。不仅数据库结构，而且可以使用任何数据源。随着Web服务/面向服务的体系结构/ ESB的出现，在一个更大的公司中，考虑更高层次的关注问题，而不是存储过程中可以获得的问题是明智的。但是，在小公司和永远不会使用不同数据源的应用程序中，SP可以很好地适应帐单。最后一点，没有必要使用OR映射器来获取抽象。我的前团队通过简单地使用Spring.NET的适配器模型插入数据源获得了巨大的成功。

Answer 7

肯定ORMs。更灵活，更便携（通常他们倾向于内置可移植性）。如果速度缓慢，您可能希望在热点中使用缓存或手动调整的SQL。

一般来说，存储过程在可维护性方面存在一些问题。

• 从应用程序分开（这么多的变化现在已经能够在两个场所进行）
• 一般很难改变
• 更难版本控制下把
• 困难，确保他们更新（部署问题）
• 可移植性（已经提到）

Answer 8

这已经在长度上前面的问题进行讨论。

What are the pros and cons to keeping SQL in Stored Procs versus Code

Answer 9

@肯特弗雷德里克

我个人的OR映射器的看法是他们的存在突出了设计上的漏洞在数据库流行结构”

我觉得你说的关于关系模型和面向对象模型的区别，这实际上是我们为什么需要ORM的原因，但是这些模型的实现是有意的 - 它不是一个设计流程 - 它只是如何事情结果是历史性的。

Answer 10

使用已识别性能瓶颈的存储过程。如果您还没有发现瓶颈，那么您如何进行过早优化？
使用您关心对特定表的安全访问的存储过程。
当您有一个准备好坐下来编写复杂查询的SQL向导时，使用存储过程可以将遗留数据库中的大量表连接在一起，以完成OR映射器中难以处理的事情。

对于其他数据库（至少）80％的数据库使用OR映射器：其中选择和更新过于常规，以至于仅通过存储过程进行访问是手动编码中毫无意义的练习，并且更新非常少没有性能成本。使用OR映射器来自动化简单的东西。

大多数OR映射器都可以与其他存储过程进行通信。

假设它们比字符串中的sql语句更快，则不应该使用存储的procs，但最后几个版本的MS SQL服务器并不一定如此。

您不需要使用存储过程来阻止SQL注入攻击，还有其他方法可以确保您的查询参数是强类型的，而不仅仅是字符串连接。

您不需要使用OR映射器来获取POCO域模型，但它确实有帮助。

Answer 11

如果你已经有一个暴露为sprocs的数据API，那么你需要证明一个主要的体系结构检修来证明ORM。

对于绿色字段建立，我会评估几件事情：

1. 如果有对球队专用的DBA，我瘦到存储过程
2. 如果有多个应用程序触摸同样DB我瘦到存储过程
3. 如果有以往没有数据库迁移的可能性，我瘦到存储过程
4. 如果我想在DB实现MVCC，我瘦到存储过程
5. 如果我将其作为产品进行部署具有潜在的多个后端DBS（MySQL和MSSQL，Oracle）的UCT，我瘦到ORM
6. 如果我在一个时间紧迫，我瘦到ORM，因为它创建我的域模型更快的方法和保持它与数据模型同步（使用适当的工具）。
7. 如果我暴露在多种方式（Web应用程序，Web服务，客户端RIA）相同的域模型，我会瘦到ORM作为然后数据模型，然后隐藏在我的ORM的外观，使得一个强大的域模型对我更有价值。

我认为性能是有点红鲱鱼; hibernate似乎比手写SQL（由于它的缓存层）表现得差不多或者更好，并且很容易在你的sproc中以不同的方式编写错误的查询。

最重要的标准可能是团队的技能和长期的数据库可移植性的需求。

Answer 12

那么SP的已经在那里了。他们真的没有意义。我猜这是有道理的使用SP的映射器吗？

Answer 13

“我想在钉子开车。我应该用我的鞋后跟或玻璃瓶？”

存储过程和ORM都很难并且很难用于开发人员（虽然不一定是DBA或架构师），因为它们会产生启动成本和更高的维护成本而不能保证支付-off。

如果要求在系统的使用期限内预计不会发生很大的变化，那么两者都会收益良好，但如果您要构建系统以便首先发现需求，它们将会阻碍您的发展。

像LINQ和ActiveRecord这样的直接编码的SQL或准ORM更适合构建到发现项目（在企业中发生的事情远比PR想要的要多）。

存储过程是在一个语言无关的环境更好，或需要超过权限的细粒度控制。如果你的DBA比你的程序员更好地理解需求，他们也会更好。

如果您使用Big Design Up Front，使用大量UML，想要抽象数据库后端，并且您的架构师比需要DBA或程序员的人更好地理解需求，那么成熟的ORM会更好。

然后有选项＃4：全部使用它们。整个系统通常不只是一个程序，尽管许多程序可能会与同一个数据库交谈，但它们都可以使用任何适合程序特定任务和其成熟度的方法。那就是：你从直接编码的SQL或LINQ开始，然后通过在ORM和存储过程中进行重构来使程序成熟，在那里你看到它们是有意义的。

Answer 14

在我的工作中，我们主要做一系列业务应用程序 - 合同工作。

对于这种类型的业务，我是ORM的粉丝。大约四年前（当ORM工具不太成熟时），我们研究了CSLA，并推出了我们自己的简化ORM工具，该工具用于大多数应用程序，包括一些具有100多个表的企业级系统。

我们估计这种方法（当然包括大量的代码生成）在我们的项目中节省了高达30％的时间。严重的是，它很荒谬。

有一个很小的性能折衷，但只要你对软件开发具有正确的理解，它就没有实质意义。总是有例外需要灵活性。

例如，如果可能的话，极其数据密集的批处理操作仍应该在专门的sprocs中处理。如果你可以在数据库中使用sproc，你可能不希望发送超过10万条记录。

这是新手开发人员遇到的问题类型，他们是否使用ORM。他们必须看到结果，如果他们能胜任，他们会得到它。

我们在Web应用程序中看到的是，即使使用ORM，通常最难解决的性能瓶颈不再与数据库相关。相反，由于带宽，AJAX开销等原因，它们在前端（浏览器）上。即使是中档数据库服务器，这些日子也非常强大。

当然，从事更大规模高需求系统的其他商店可能会有不同的体验。 :)

Answer 15

关于存储过程没有什么好的说法。 10年前有必要，但使用sprocs的每一个好处都不再有效。两个最常见的论点是关于安全性和性能。 “通过电线发送东西”垃圾也不具备，我当然可以动态地创建一个查询来执行服务器上的所有操作。 sproc支持者不会告诉您的一件事是，如果您在合并出版物上使用列冲突解决方案，则更新将无法进行。只有认为自己是数据库霸主的DBA坚持使用sprocs，因为它使他们的工作看起来比实际更令人印象深刻。