社交网站的ORM是否有意义？

Question

我之所以这样问是因为我需要知道在社交网站上使用ORM是否有任何意义。

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

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

基于我有限的经验，这是我有限的理解。您在构建社交网站方面有什么经验？我的观点有效吗？在不担心使用ORM的情况下使用裸SQL是否蹩脚？ ORM可以帮助建立社交网站有什么意义？

Answer 1

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

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

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

使用ORM与不使用ORM似乎不会对可伸缩性产生巨大影响。其他可降低扩展性的技术包括：

• 管理RDBMS中的索引。从O（n）到O（log ₂ n）尽可能多地改进算法。
• 智能缓存架构。
• 通过数据库分区/分片进行水平扩展。
• 数据库负载平衡和复制。尽可能从从数据库中读取，并写入单个主数据库。指数奴隶和主人不同。
• 使用互补技术补充RDBMS，例如Sphinx Search。
• 通过向问题投掷硬件来进行垂直缩放。 Jeff Atwood在StackOverflow播客上对此进行了评论。

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

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

---

编程实体框架（2009）中的Julia Lerman，第503页显示，直接使用DataReader和使用Microsoft的LINQ to Entities之间的查询执行成本增加了220％。

另见Jeff Atwood在All Abstractions are Failed Abstractions上的帖子，他表示使用LINQ至少是以简单的方式使用纯SQL的两倍。

Answer 2

以下是我对你的观点的回应：

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

Answer 3

IMO，ORM可以帮助您编写更清晰，更清晰的代码。如果你使用它可能会导致过多的查询，但这绝不是一个规则。如果我是你，我会开始使用框架的ORM和最佳实践，如果你发现自己需要ORM不提供的功能，那么只需要删除SQL。

Answer 4

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

Answer 5

IMHO。需要ORM。

1. 它允许您以OOP方式访问数据库，无论是否有多个数据库。

   1. 更清洁的代码，你可以在表类文件中定义与特定表相关的所有方法，如果你需要原始的sql join查询，没问题，定义那里。它跟随DRY和KISS。它比你一次又一次地编写类似的原始sql查询要好得多。

Answer 6

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