database - ORM vs 传统数据库查询，它们的领域是什么？

Question

ORM 似乎是一个快速发展的模型，有利有弊。来自 Richard Kiessig (http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b) 的 Ultra-Fast ASP.NET:

“我喜欢它们，因为它们让我能够非常快速地开发小型的概念验证网站。我可以避开很多 SQL 和相关的复杂性，否则我需要专注于对象、业务逻辑和表示. 然而，与此同时，我也不关心它们，因为不幸的是，它们的性能和可扩展性通常很差，即使当它们与一个全面的缓存系统集成时也是如此(当你意识到这一点时，原因就很清楚了)如果配置得当，SQL Server 本身实际上只是一个大数据缓存”

我的问题是:

• 您对 Richard 的想法有何评论？你同意他的看法吗？如果不是，请说明原因。

• ORM和传统数据库查询最适合的字段是什么？换句话说，你应该在哪里使用 ORM，在哪里你应该使用传统数据库查询 :)，哪种类型/规模...你无疑应该选择 ORM/传统数据库查询

提前致谢

Answer 1

我不同意对 ORM 表现不佳的普遍提示。到目前为止，我见过很多纯 SQL 应用程序。虽然理论上可以编写优化的 SQL，但实际上，它们会通过编写未优化的业务逻辑来破坏所有性能提升。

当使用纯 SQL 时，业务逻辑与数据库模型高度耦合，数据库操作和优化取决于业务逻辑。因为没有 oo 模型，你不能传递整个对象结构。我见过许多应用程序传递主键并一次又一次地从每一层的数据库中检索数据。我见过循环访问数据库的应用程序。等等。问题是:因为业务逻辑已经很难维护了，没有再优化的空间了。通常，当您尝试至少重用部分代码时，您会承认它并未针对每种情况进行优化。性能因设计而变差。

ORM 通常不需要业务逻辑过多关心数据访问。 ORM 中实现了一些优化。有缓存和批处理能力。这种自动(和运行时动态)优化并不完美，但它们将业务逻辑与其分离。例如，如果有条件地使用一段数据，它会根据请求(恰好一次)使用延迟加载来加载它。您无需执行任何操作即可实现这一目标。

另一方面，ORM 的学习曲线陡峭。我不会将 ORM 用于琐碎的应用程序，除非该 ORM 已被同一团队使用。

ORM 的另一个缺点是(实际上不是 ORM 本身的缺点，而是您将使用关系数据库和对象模型的事实)，团队需要在两个方面都很强大，关系数据库也是如此作为面向对象。

结论:

• ORM 非常适用于以业务逻辑为中心的应用程序，这些应用程序的数据结构足够复杂，因此拥有 OO 模型将大有裨益。
• ORM 通常有一个(不知何故)陡峭的学习曲线。对于小型应用程序，它可能会变得过于昂贵。
• 基于简单数据结构的应用程序，没有太多的逻辑来管理它，很可能更容易和直接地用普通 sql 编写。
• 具有高水平数据库知识且在 oo 技术方面经验不多的团队使用普通 sql 很可能会更有效率。 (当然，根据他们编写的应用程序，建议团队转移重点)
• 拥有高水平 oo 知识和基本数据库经验的团队使用 ORM 最有可能提高效率。 (此处相同，根据他们编写的应用程序，建议团队转移焦点)