O/R 映射值得吗？

Posted 2023-04-12

【中文标题】O/R 映射值得吗？

【英文标题】：Is O/R Mapping worth it?

【发布时间】：2008-10-07 16:29:54

【问题描述】：

ORM 提供的查询语言 (QL) 的表达能力非常强大。不幸的是，一旦您有一组复杂的查询，然后出现一些令人费解的模式或数据问题，就很难获得您需要的 DBA 帮助？他们是开发数据库的团队的一部分，但他们无法读取应用程序 QL，更不用说提出修改建议了。我通常最终会为他们从日志中获取生成的 SQL。但是，当他们建议对其进行更改时，这与原始 QL 有何关系？该过程不是往返的。

所以在宣传 ORM 的价值十年之后，我现在想知道是否应该手动编写我的 SQL。也许我真正希望框架做的只是尽可能地自动化数据编组。

问题：您是否找到了解决组织中往返问题的方法？是否有可扩展且易于维护的 SQL 编组框架？

（是的，我知道纯 SQL 可能会将我绑定到数据库供应商。但 可以编写符合标准的 SQL。）

【问题讨论】：

值得深思，这里是 Ted Neward 的大量文章“计算机科学的越南”：blogs.tedneward.com/2006/06/26/…

更新链接blogs.tedneward.com/post/the-vietnam-of-computer-science

【参考方案1】：

我认为您想要的是一种解决方案，可以最大限度地发挥 ORM 的优势，同时又不妨碍您使用其他方式。在我们的应用程序中，我们遇到的问题与您的问题大致相同；非常繁重的查询和大型数据模型。鉴于数据模型的大小，ORM 对于绝大多数应用程序来说都是无价的。它允许我们扩展数据模型，而无需花费大量精力手动维护 SQL 脚本。此外，您也谈到了这一点，我们支持四个数据库供应商，所以抽象很好。

但是，在某些情况下，我们不得不手动调整查询，而且由于我们选择了灵活的 ORM 解决方案，我们也可以这样做。正如您所说，当我们需要它时它会自动消失，并为我们简单地编组对象。

所以，简而言之（是的，简而言之）是的，ORM 是值得的，但就像解决问题的所有方法一样，它不是万能药。

【参考方案2】：

一般来说，ORM 可以大大提高开发人员的工作效率，所以我会使用它们，除非它们已经成为一个比其价值更大的问题。如果您的大多数表都足够大以至于您遇到很多问题，请考虑放弃 ORM。我绝对不会说 ORM 通常是一个坏主意。大多数数据库都足够小，大多数查询也足够简单，可以很好地工作。

我已经通过使用存储过程或仅针对性能不佳的查询的手写 SQL 克服了这个问题。 DBA 喜欢存储过程，因为他们可以在不告诉您的情况下修改它们。大多数（如果不是全部）ORM 允许您混合手写 SQL 或存储过程。

【参考方案3】：

我相信您熟悉的今天的 O/R 框架支持手动定义一些查询的选项（(N)Hibernate 确实如此）。可用于模式的复杂部分，对于直截了当的部分，请使用框架提供的 ORM。

您要检查的另一件事可能是 iBatis 框架 (http://ibatis.apache.org/)。我没有使用过它，但我读到它更接近 SQL，熟悉数据库和 SQL 的人更喜欢它而不是像 hibernate 这样的成熟 ORM 框架，因为它比完全不同的 ORM 概念更接近它们。