【发布时间】：2009-05-12 21:23:27
【问题描述】：
如果我使用存储过程，我可以使用 ORM 吗？
编辑：
如果我可以使用 ORM，这是否会破坏使用 ORM 的数据库不可知性的部分原因？换句话说，如果我将自己绑定到具有存储过程的特定数据库（或者这种假设是否错误），我为什么还要使用 ORM？
【问题讨论】：
标签： stored-procedures orm
【发布时间】：2009-05-12 21:23:27
【问题描述】：
使用 ORM 访问存储过程是 ORM 的最佳用途之一。它将为您提供强类型对象，同时您仍然可以完全控制 SQL。
【讨论】：
-
如果您的语言是强类型的，这很好。当您使用 PHP 之类的东西时，您需要检查参数的代码。这并不意味着您不能拥有不会为您执行此操作的 ORM 或代码生成器。示例案例：我开发了一个代码生成器，它为 Postgresql 函数编写访问包装器并将它们公开为 SOAP Web 服务。因为我不想编写额外的代码来检查标量参数，所以我添加了一个函数，因为 PHP 不支持标量类型提示 (github.com/sylnsr/pgfunc2php/blob/master/pgsupport.lib.php)
根据我的经验，我会让 ORM 处理“CRUD”操作，而将专业工作留给存储过程。通常，将存储过程用于“CRUD”操作是多余的，让 ORM 处理它可以大大提高您的工作效率。
【讨论】：
是的，你可以，所有主要的 ORM 都支持存储过程。
至于您的假设，您是特别正确的，当您将存储过程与 ORM 一起使用时，您将项目耦合到特定数据库。但实际上 99% 的情况是您不需要更改数据库提供程序，因此在这种情况下，您使用 ORM 不是为了从具体的数据库提供程序中抽象出来，而是帮助自己完成对象关系映射任务——这是 ORM 的主要任务以及最初是为哪个 ORM 制作的。
【讨论】：
它提出了一个有趣的观点。
一旦有了 ORM 和相对简单的查询，为什么还需要存储过程？ SP 与数据库密切相关。 ORM 使您不必维护大量特定于 DB 的代码。什么是 DB-specific 可以被隔离和管理。
我建议 ORM 是降低复杂性并将所有处理放在它所属的代码中的绝佳机会。
将数据库用于它最擅长的事情——存储数据。
将您的应用程序用于其最擅长的事情——处理数据。
【讨论】：
-
这不是一场激烈的辩论吗？ SP 与无 SP。
-
有些人喜欢辩论它。我们中的其他人厌倦了试图维护损坏的存储过程并触发垃圾缠结。 ORM 从 SP 的复杂性中解放出来的想法对我们中的一些人非常有吸引力。
-
如果它们真的是“简单查询”，那没有问题。已经有很多SP滥用了。当应用程序被滥用并执行显然属于数据库服务器领域的处理时，问题就开始了 - 处理大型结果集。当您需要在网络中抛出 50k 行只是为了遵守“使用您的应用程序做它最擅长的事情 - 处理数据”的想法 - 就像一个宗教教条 - 很明显，存储过程可以更好地处理处理。
-
“将您的应用程序用于它最擅长的事情——处理数据。” --> 嗯，所有顶级 RDBMS 都非常擅长处理数据，并且比您的应用程序更快。 SQL 的存在不仅是为了存储数据，而且是为了处理数据。我想说你的推理适用于某些不支持数据处理的 NoSQL 数据库。
您可以同时使用 ORM 功能和存储过程功能。特别是使用 ORM 直到它适合您，但如果您在性能方面遇到问题或需要一些低级调整 - 在您的业务逻辑中包含存储过程。
【讨论】：
是的，您可以，但您需要花一些时间研究 ORM 围绕存储过程提供了哪些功能。
大多数将允许您运行返回强类型对象/实体的存储过程。更高级的 ORM 将允许您插入存储过程以执行 CRUD 操作（因此您的通用查询、删除等通过存储过程而不是动态查询进行）。
通常，ORM 非常适合生成临时查询和获取强类型实体，但具有强大的存储过程支持的好处是允许您（有时）更轻松地访问您的 RDMS 的本机功能，这些本机功能可能不会作为第一类公开ORM 中的公民 - 特别是如果 ORM 支持许多数据库引擎。
跟进您的编辑：
通常您会想要使用 ORM 提供的即席查询引擎，但是正如我之前提到的 - 有时您想要使用 ORM 未公开的功能进行查询。
强类型实体的好处是无价的，因为这意味着您通常拥有域对象，而不是数据读取器、数据表等。您可以在检索到的实体中清晰地封装行为和逻辑。
其他好处的列表确实很长 - 例如，使用 LightSpeed ORM（和大多数其他），您的实体将支持标准绑定接口、错误报告接口、验证等。在查询方面，您将失去惰性加载等，除非你自己写。
【讨论】：
数据库“不可知性”(?) 并不是使用 ORM 的唯一原因。但是，您可以利用与数据库交互的 99% 独立于数据库，并且在 1%（或 2% 或 10% 或其他）中，您可能需要存储过程来提高速度/清晰度/复杂性。如果您更改了 DB，则需要重写它们。
【讨论】：
我在工作中经常使用 netTiers，我们让它为我们生成存储过程。这些只处理基本的 CRUD 操作，但它们非常快并且为我节省了大量时间。 netTiers 还将让我们创建自定义存储过程并使用这些过程生成我们的数据访问代码。
【讨论】：
可以，但许多更高级的 ORM 功能往往会变得更麻烦。 iBatis 之类的东西很容易与存储过程集成，而更复杂的引擎（如 (N?)Hibernate 之类的动态 SQL 生成和大字段的延迟加载）的更复杂的功能可能会变得比它们更麻烦值得。
【讨论】：
我相信任何能让你从重复工作中解放出来并专注于解决问题的工具都是有效的。当涉及到基本的 CRUD 操作时，ORM 似乎就是那种工具——即使使用 SP 来更好地实现需求（比如在钉子上使用锤子，它只是完成任务的正确工具）。
重点是：没有黑色或白色，只有灰色的刻度。非常无能和编码错误的应用程序以“与数据库无关”为借口来解释数据库资源的过度使用。在许多情况下，与数据库紧密联系也不好。目标是：在不浪费客户 IT 资源的情况下获得最大程度的“数据库不可知论”。
没有“旧与新”之分，只是人们说极端“纯粹”的方法更好。我真的不相信。我相信，与任何工具一样，“最佳”（注意引号）方法是使用 ORM，直到仍然是使您的数据访问的正确工具。当您达到浪费资源并降低可伸缩性和 TI 资源的“价值生活”（我忘记了葡萄牙语“vida útil”的英文表达）的程度时，请在 ORM 中使用 SP。或者，换句话说，当它用于手头的处理时，使用 SP 就像锤子用于钉子一样。
【讨论】：