sql - 使用 ORM 还是普通 SQL？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 9 年前。

社区去年审查了是否重新开放此问题，并将其关闭:

原始关闭原因未解决

Improve this question

对于我开发的一些应用程序(然后逐渐忘记)，我一直在编写简单的 SQL，主要是为 MySQL 编写的。虽然我在 python 中使用过 ORM，比如 SQLAlchemy ，我并没有和他们坚持多久。通常是文档或复杂性(从我的角度来看)阻碍了我。

我是这样看的:使用 ORM 来实现可移植性，如果只使用一种类型的数据库，则使用纯 SQL。我确实在寻求有关在开发需要数据库支持的应用程序时何时使用 ORM 或 SQL 的建议。

想一想，与使用 ORM 相比，仅使用轻量级包装器来处理数据库不一致要好得多。

Answer 1

作为一个花了相当多时间使用 JPA(Java Persistence API，基本上是 Java/J2EE/EJB 的标准化 ORM API)的人，其中包括 Hibernate、EclipseLink、Toplink、OpenJPA 等，我将分享我的一些观察。

1. ORM 速度并不快。它们可能足够了，而且大多数时候足够了就可以了，但在大容量低延迟环境中它们是不行的；
2. 在 Java 和 C# 等通用编程语言中，您需要大量的魔法才能使它们正常工作(例如 Java 中的加载时编织、检测等)；
3. 当使用 ORM 时，您会惊讶地发现您花费了多少时间来调整 XML 和/或注释/属性以使 ORM 生成高性能 SQL，而不是进一步远离 SQL(这似乎是其意图)；
4. 对于复杂的查询，确实没有替代品。就像在 JPA 中一样，有一些查询根本不可能在原始 SQL 中使用，当您必须在 JPA 中使用原始 SQL 时，这不太好(C#/.Net 至少有动态类型 - var - 这是很多比对象数组更好)；
5. 使用 ORM 时会遇到很多“陷阱”。这包括意外或意外的行为，事实上，您必须内置对数据库进行 SQL 更新的功能(通过在 JPA 中使用刷新()或类似方法，因为 JPA 默认情况下会缓存所有内容，因此它不会捕获直接数据库更新——运行直接 SQL 更新是常见的生产支持事件)；
6. 对象关系不匹配总是会导致问题。对于任何此类问题，都需要在抽象的复杂性和完整性之间进行权衡。有时我觉得 JPA 走得太远，触及了真正的 yield 递减法则，其中复杂性的打击并不能通过抽象来证明是合理的。

还有一个问题需要更多解释。

Web 应用程序的传统模型是具有持久层和表示层(中间可能有服务或其他层，但这些是本次讨论的重要两层)。 ORM 强制从持久层到表示层(即您的实体)采用严格的 View 。

对更原始 SQL 方法的批评之一是，您最终会得到仅由一个查询使用的所有这些 VO(值对象)或 DTO(数据传输对象)。这被认为是 ORM 的一个优势，因为你可以摆脱它。

事实是，这些问题并不会随着 ORM 的出现而消失，它们只是向上移动到表示层。您无需为查询创建 VO/DTO，而是创建自定义表示对象，通常为每个 View 创建一个对象。这如何更好？恕我直言，事实并非如此。

我在 ORM or SQL: Are we there yet? 中写过相关内容.

最近我选择的持久化技术(Java)是ibatis。它是 SQL 的一个非常薄的包装器，可以完成 JPA 90% 以上的功能(它甚至可以延迟加载关系，尽管它没有详细记录)，但开销要少得多(就复杂性和实际代码而言)。

这在我去年编写的 GWT 应用程序中出现过。服务实现中从 EclipseLink 到表示对象的大量转换。如果我们使用 ibatis，那么使用 ibatis 创建适当的对象然后在堆栈中上下传递它们会简单得多。一些纯粹主义者可能会认为这很糟糕™。也许是这样(理论上)，但我告诉你:这会导致更简单的代码、更简单的堆栈和更高的生产力。