用于社交网站的 ORM 是否有意义？答案

【问题标题】：Does ORM for social networking sites makes any sense?用于社交网站的 ORM 是否有意义？
【发布时间】：2010-01-26 03:09:49
【问题描述】：

我问这个的原因是因为我需要知道在社交网站上不使用 ORM 是否有任何意义。

我为什么 ORM 不适合社交网站的论点是：

社交网站不是产品，因此您不需要支持多个数据库。您知道要使用什么数据库，而且您很可能不会时不时地更改它。
社交网站需要用户之间的多对多关系，最终有时您需要编写简单的 SQL 来获取这些关系。 ORM的值因此再次下降。
与上一点相关，ORM 有时会在后端进行多次查询以获取其记录，这有时可能效率低下，并可能导致数据库出现瓶颈。最后你必须写下简单的 SQL 查询。如果我们知道无论如何都要编写纯 SQL，那么使用 ORM 有什么意义？

这是我基于有限经验的有限理解。您在构建社交网站方面有什么经验？我的积分有效吗？使用裸 SQL 而不用担心使用 ORM 是不是很蹩脚？ ORM 可以在哪些方面帮助构建社交网站？

【问题讨论】：

您的论点要么是错误的、不相关的，要么仅适用于使用关系数据库作为后端的任何程序。
拜托，我已经说过这是基于我有限的理解和有限的经验，所以它可能是错误的。阅读时不要只是略读。
@hop，是的，我可以说这是 jpartogi 提出的一个真正的问题，他想向他人学习并获得自己意见的反馈。

标签： sql language-agnostic orm social-networking web-frameworks

【解决方案1】：

使用 ORM 的价值在于帮助加快开发速度，通过将查询结果分配给对象字段的繁琐工作自动化，并跟踪对象字段的更改，以便您可以将它们保存到数据库中.因此，术语对象-关系映射。

在数据库可移植性方面，ORM 对您没有什么价值，因为您只使用您部署的一个数据库。

ORM 的运行时性能方面并不比自己编写纯 SQL 好，而且通常比自己编写的 SQL 差很多。正如您所提到的，查询生成的通用方法经常会犯幼稚的错误并导致冗余查询。同样，好处在于开发时间，而不是运行时效率。

使用 ORM 与不使用 ORM 似乎对可伸缩性没有太大的影响。其他更具可扩展性的技术包括：

在 RDBMS 中管理索引。将尽可能多的算法从 O(n) 改进到 O(log₂n)。
智能缓存架构。
通过数据库分区/分片进行水平扩展。
数据库负载平衡和复制。尽可能从从属数据库读取，并写入单个主数据库。以不同方式索引从属和主控。
为 RDBMS 补充补充技术，例如 Sphinx Search。
通过将硬件投入问题进行垂直缩放。 Jeff Atwood 在 StackOverflow 播客上对此发表了评论。

有些人主张将您的数据管理转移到使用云计算或分布式非关系数据库的分布式架构中。在您获得大量用户之前，这可能不是必需的。一旦增长到一定程度，所有规则都会改变，您可能无论如何都无法使用 RDBMS。但除非你是雅虎、Facebook 或 LinkedIn 的数据架构师，否则不要担心——云计算被过度炒作了。

普遍认为数据库始终是 Web 应用程序的瓶颈，但也有一种情况是，提高前端的效率至少同样重要。参照。 Steve Souders的书籍。

Julia Lerman 在Programming Entity Framework (2009) 第 503 页中表明，直接使用 DataReader 和使用 Microsoft 的 LINQ to Entities 之间的查询执行成本增加了 220%。

另请参阅 Jeff Atwood 在 All Abstractions are Failed Abstractions 上的帖子，其中他表明使用 LINQ 的成本至少是使用纯 SQL 的两倍，即使是以一种幼稚的方式。

【讨论】：

"(...) 通常比自己编写普通 SQL 更糟糕" 我不太同意，尤其是在“很多”方面（一个好的 ORM 实际上会产生很多比大多数开发人员更好的 SQL，但假设这不适用于这里）。
@Pascal：毫无疑问，有关于高效 ORM 和浪费 ORM 的轶事案例。我的观点仍然是，ORM 的主要好处在于开发效率，而不是运行时效率。
@Bill 我仍然认为使用 good ORM 可以在不牺牲性能的情况下同时获得开发速度。实际上，我相信延迟加载、一级缓存、二级缓存、查询缓存之类的东西会有所帮助。这并不意味着您不必进行一些调整。而且，一个好的 ORM 将允许您这样做。不过我明白你的意思。无论如何，感谢您的反馈（和好的答案）。
@Pascal：你能举一个满足这些标准的good ORM 的例子吗？我不是要争论——我真的很好奇。
@Bill Hibernate。也许是 EclipseLink（前 Oracle Toplink），但我不能 100% 确定它的缓存功能（尽管我知道您可以使用 Oracle Toplink + Oracle Coherence）。

【解决方案2】：

这是我对您的观点的回应：

ORM 并不需要多个数据库才能生效，实际上大多数情况下使用 ORM 并不是因为能够适应不同的数据库。
大多数现代 ORM 框架都足够灵活，可以获取映射类的“轻量级”变体，这实际上取决于您如何实现它们。
如果确实需要，您可以在 ORM 框架内编写本机 SQL 查询。请注意，缓存和性能相关算法通常是这些框架的一部分。

【讨论】：

我们真的使用 ORM 提供的缓存吗？最后，我看到人们使用数据库提供的缓存或 memcached。
我同意缓存是一把双刃剑，您需要了解它才能正确/有效地使用它。这是一篇关于它的有趣文章queue.acm.org/detail.cfm?id=1394141

【解决方案3】：

IMO，ORM 可帮助您编写更简洁、更清晰的代码。如果你随意使用它，你可能会导致过多的查询，但这绝不是一个规则。如果我是你，我会开始使用 ORM 和框架的最佳实践，并且只有在你发现自己需要 ORM 不提供的功能时才使用 SQL。

【讨论】：

【解决方案4】：

还要注意，在 Web 应用程序中，许多人正在远离 SQL 数据库。 ORM 可能会帮助您迁移到非关系数据库（正是因为您的应用程序代码中没有 SQL）。看看 JDO 和 JPA 在 Google 的 App Engine 中的使用。

【讨论】：

【解决方案5】：

恕我直言。需要ORM。

它允许您以OOP方式访问数据库，无论是否有多个数据库。
1. 更简洁的代码，您可以在表类文件中定义与特定表相关的所有方法，如果您需要原始sql连接查询，没问题，定义在那里。它遵循 DRY 和 KISS。这比你一遍又一遍地编写类似的原始 sql 查询要好得多。

【讨论】：

【解决方案6】：

您的网站足够大以至于扩展成为问题的可能性非常小，那么为什么要过早地通过使用原始 SQL 而不是 ORM 来进行优化呢？假设数据库和应用程序设计不错，您可以通过在数据库中投入更好的硬件来取得相当大的进展。虽然您可能需要为创建朋友图之类的事情编写原始 SQL，但是当有人更改电子邮件、发送私人消息、上传照片等所有小事情（例如更新数据库）时呢？使用 ORM 可以简化您必须完成的所有简单数据库任务，同时仍然允许您在绝对必要的地方手动编写代码。

【讨论】：