存储过程还是OR映射器？

Question

哪个更好？或者使用和OR映射器与SP？如果你的系统已经有SP，那么OR映射器是否值得？

Answer 1

我喜欢ORM，因为你不需要重新发明轮子。话虽如此，它完全取决于您的应用需求，开发风格和团队的需求。

此问题已涵盖Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 2

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

Answer 3

以前的问题对此进行了详细讨论。

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

Answer 4

在我的工作中，我们主要开展业务应用程序 - 合同工作。

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

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

有一个小的性能权衡，但只要你对软件开发有一个正确的理解，它就是非实质性的。总有一些例外需要灵活性。

例如，如果可能的话，仍应在专门的sprocs中处理极其数据密集的批处理操作。如果您可以在数据库中直接执行此操作，则可能不希望通过线路发送100,000个大型记录。

这是新手开发者遇到的问题，无论他们是否使用ORM。他们只需要看到结果，如果他们有能力，他们就会得到它。

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

当然，在更大的高需求系统上工作的其他商店可能会有不同的体验。 :)

Answer 5

存储过程放下。或者Mappers是特定于语言的，并且通常会增加图形减速。

存储过程意味着您不受语言界面的限制，您只能以向前兼容的方式处理数据库的新接口。

我对OR Mappers的个人看法是它们的存在突出了流行的数据库结构中的设计缺陷。数据库开发人员应该实现人们尝试使用复杂的OR-Mappers完成的任务，并创建有助于执行此任务的服务器端实用程序。

OR Mappers也是“漏洞抽象”综合症的史诗目标（Joel On Software: Leaky Abstractions）

由于抽象层不是通灵的，它很容易找到它无法处理的东西。

Answer 6

在我看来，存储过程更好，因为它们可以从基础表中获得独立的安全配置。

这意味着您可以允许特定操作，而不允许对特定表进行写入/读取。它还限制了人们发现SQL注入攻击时可以造成的损害。

Answer 7

绝对 ORMs 。更灵活，更便携（通常它们往往具有内置的可移植性）。如果速度很慢，您可能希望在热点中使用缓存或手动调优的SQL。

通常，存储过程在可维护性方面存在一些问题。

• 与申请分开（现在在两个地方进行了很多更改）
• 一般难以改变
• 更难置于版本控制之下
• 更难确保更新（部署问题）
• 便携性（已提及）

Answer 8

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

Answer 9

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

Answer 10

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

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

Answer 11

@ Kent Fredrick

  

我个人对OR Mappers的看法是他们的存在凸显了流行的数据库结构中的设计缺陷“

我认为你在谈论关系模型和面向对象模型之间的区别。这实际上是我们需要ORM的原因，但这些模型的实现是故意完成的 - 它不是一个设计流程 - 它只是历史上的结果。

Answer 12

使用已识别性能瓶颈的存储过程。如果你还没有发现瓶颈，你在做什么过早优化？ 如果您担心对特定表的安全访问，请使用存储过程 如果您有一个准备坐下来编写复杂查询并将旧数据库中的大量表连接在一起的SQL向导，则使用存储过程来执行OR映射器中很难处理的事情。

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

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

你不应该使用存储过程，假设它们比字符串中的sql语句更快，在最后几个版本的MS SQL服务器中不一定是这种情况。

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

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

Answer 13

如果您已经有一个公开为sprocs的数据API，那么您需要证明进行主要的体系结构改革才能进入ORM。

对于绿色领域的构建，我会评估几件事：

1. 如果团队中有专门的DBA，我会倾向于sprocs
2. 如果有多个应用程序触及相同的数据库，我会倾向于使用sprocs
3. 如果没有数据库迁移的可能性，我会倾向于sprocs
4. 如果我想在数据库中实现MVCC，我会倾向于使用sprocs
5. 如果我将其部署为具有潜在多个后端dbs（MySql，MSSql，Oracle）的产品，我会倾向于ORM
6. 如果我的时间紧迫，我会倾向于ORM，因为这是创建我的域模型并使其与数据模型保持同步的更快方式（使用适当的工具）。
7. 如果我以多种方式暴露相同的域模型（Web应用程序，Web服务，RIA客户端），我将倾向于ORM，然后数据模型隐藏在我的ORM外观背后，使得强大的域模型成为可能对我来说更有价值。

我觉得表演有点像红鲱鱼; hibernate似乎与手工编写的SQL几乎一样好或更好（由于它的缓存层），并且很容易在你的sproc编写错误的查询。

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

Answer 14

SP已经存在了。他们真的没有意义。我想使用SP的映射器是否有意义？

Answer 15

“我正试着开钉子。我应该使用鞋跟或玻璃瓶吗？”

存储过程和ORM对于开发人员来说都很困难且令人烦恼（虽然不一定分别用于DBA或架构师），因为它们会产生启动成本和更高的维护成本，而这些成本并不能保证支付 - 关闭。

如果要求预计在系统的整个生命周期内都不会发生太大的变化，那么两者都会得到很好的回报，但如果您正在构建系统以首先发现需求，它们将会妨碍您。

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

存储过程在与语言无关的环境中更好，或者需要对权限进行细粒度控制。如果你的DBA比你的程序员更好地掌握需求，那么他们也会更好。

如果你做Big Design Up Front，使用大量的UML，想要抽象数据库后端，你的架构师比DBA或程序员更好地掌握需求，那么全面的ORM会更好。

然后是选项＃4：使用所有这些选项。整个系统通常不只是一个程序，虽然许多程序可能与同一个数据库通信，但它们每个程序都可以使用适合程序特定任务的适当方法，以及它的成熟程度。那就是：你从直接编码的SQL或LINQ开始，然后通过重构ORM和存储过程来使程序成熟，你可以看到它们是有意义的。