我之所以问这个问题是因为我需要知道在社交网站上不使用 ORM 是否有任何意义。
我的理由是 ORM 不适合社交网站：
- 社交网站不是产品，因此不需要支持多个数据库。您知道要使用什么数据库，并且很可能不会时不时地更改它。
- 社交网站需要用户之间存在多对多关系，最终有时您需要编写简单的 SQL 来获取这些关系。 ORM的价值因此再次降低。
- 与上一点相关，ORM 有时会在后端执行多个查询来获取其记录，这有时可能效率低下，并可能导致数据库瓶颈。最后你必须写下简单的 SQL 查询。如果我们知道无论如何我们都会编写纯 SQL，那么使用 ORM 有何意义？
这是我基于有限经验的有限理解。您在建立社交网站方面有哪些经验？我的积分有效吗？使用裸 SQL 而不担心使用 ORM 是不是很蹩脚？ ORM 在构建社交网站时可以帮助哪些点？
The reason why I ask this is because I need to know whether not using ORM for a social networking site makes any sense at all.
My argument why ORM does not fit into social networking sites are:
- Social networking sites are not a product, thus you don't need to support multiple database. You know what database to use, and you most likely won't change it every now and then.
- Social networking sites requires many-to-many relationship between users, and in the end sometimes you will need to write plain SQL to get those relations. The value of ORM is thus decreased again.
- Related to the previous point, ORM sometimes do multiple queries in the backend to fetch its record, which sometimes may be inefficient and may cause bottleneck in the database. In the end you have to write down plain SQL query. If we know we are going to write plain SQL anyway, what is the point using ORM?
This is my limited understanding based on my limited experience. What are you're experience with building a social networking sites? Are my points valid? Is it lame to use bare SQL without worrying about using ORM? What are the points where ORM may help in building a social networking sites?
发布评论
评论（6）
使用 ORM 的价值在于通过自动执行将查询结果分配给对象字段的繁琐工作以及跟踪对象字段的更改以便将它们保存到数据库来帮助加快开发。因此出现了术语“对象关系映射”。
在数据库可移植性方面，ORM 对您来说没有什么价值，因为您只使用部署的一个数据库。
ORM 的运行时性能并不比您自己编写纯 SQL 更好，而且通常更差。正如您所提到的，查询生成的通用方法经常会犯幼稚的错误并导致冗余查询。同样，好处在于开发时间，而不是运行时效率。
使用 ORM 与不使用 ORM 似乎对可扩展性没有太大影响。其他更划算的可扩展性技术包括：
有些人主张使用云计算或分布式非关系数据库将数据管理转移到分布式架构。在您获得大量用户之前，这可能是不必要的。一旦规模增长到一定程度，所有规则都会发生变化，并且您可能无法使用 RDBMS。但除非您是雅虎、Facebook 或 LinkedIn 的数据架构师，否则不要担心——云计算被过度炒作了。
人们普遍认为数据库始终是 Web 应用程序的瓶颈，但也有一种情况认为提高前端效率至少同样重要。比照。 Steve Souders 的书籍。
Julia Lerman 在编程实体框架 (2009)，第 503 页中表明，直接使用 DataReader 与使用 Microsoft 的 LINQ to Entities 相比，查询执行成本增加了 220%。
另请参阅 Jeff Atwood 的帖子 所有抽象都是失败的抽象，其中他表明，使用 LINQ 的成本至少是使用普通 SQL 的两倍，即使是以简单的方式也是如此。
The value of using an ORM is to help speed up development, by automating the tedious work of assigning query results to object fields, and tracking changes to object fields so you can save them to the database. Hence the term Object-Relational Mapping.
An ORM has little value for you regarding database portability, since you only use the one database you deploy on.
The runtime performance aspect of an ORM is no better than, and typically much worse than writing plain SQL yourself. The generic methods of query generation often make naive mistakes and result in redundant queries, as you have mentioned. Again, the benefit is in development time, not runtime efficiency.
Using an ORM versus not using an ORM doesn't seem to make a huge difference for scalability. Other techniques with more bang-for-the-buck for scalability include:
Some people advocate moving your data management to a distributed architecture using cloud computing or distributed non-relational databases. This is probably not necessary until you get a very large number of users. Once you grow to a certain level of magnitude, all the rules change and you probably can't use an RDBMS anyway. But unless you are the data architect at Yahoo or Facebook or LinkedIn, don't worry about it -- cloud computing is over-hyped.
There's a common wisdom that the database is always the bottleneck in web apps, but there's also a case that improving efficiency on the front-end is at least as important. Cf. books by Steve Souders.
Julia Lerman in Programming Entity Framework (2009), p.503 shows that there's a 220% increase in query execution cost between using a DataReader directly and using Microsoft’s LINQ to Entities.
Also see Jeff Atwood's post on All Abstractions are Failed Abstractions, where he shows that using LINQ is at least double the cost of using plain SQL even in a naive way.
以下是我对您的观点的回应：
Here's my response to your points:
在我看来，ORM 可以帮助您编写更干净、更清晰的代码。如果你不小心使用它，可能会导致过多的查询，但这无论如何都不是规则。如果我是你，我会开始使用 ORM 和框架的最佳实践，并且只有在你发现自己需要 ORM 不提供的功能时才会使用 SQL。
IMO, an ORM helps you write cleaner, clearer code. If you use it sloppily you can cause excessive queries, but that isn't a rule by any means. If I were you I would start using the ORM and best practices of a framework, and only drop to SQL if you find yourself needing functionality that the ORM does not provide.
您的网站足够大而导致扩展成为问题的可能性非常小，那么为什么要通过原始 SQL 而不是 ORM 来过早地进行优化呢？假设数据库和应用程序设计都不错，那么通过在数据库上投入更好的硬件，您可以取得相当大的成果。虽然您可能需要为创建好友图表之类的事情编写原始 SQL，但当有人更改电子邮件、发送私人消息、上传照片等时更新数据库等所有小事情又如何呢？使用 ORM 可以简化您必须执行的所有简单数据库任务，同时仍然允许您在绝对必要的地方手动编写代码。
The odds of your site being big enough that scaling becomes an issue are quite small so why prematurely optimize by doing everything in raw SQL instead of an ORM? You can get fairly far by throwing better hardware at a database assuming the database and application design are decent. While you may need to write raw SQL for things like creating friend graphs what about all the little things like updating the database when someone changes there email, sends a private message, uploads a photo, etc? Using an ORM can simplify all the simple database tasks you will have to do while still allowing you to hand code where absolutely necessary.
另请注意，在 Web 应用程序中，许多人正在放弃 SQL 数据库。 ORM 可能会帮助您迁移到非关系数据库（正是因为您的应用程序代码中没有 SQL）。看看Google App Engine 中JDO 和JPA 的使用。
Also note that in web applications, many people are moving away from SQL databases. An ORM might help you to migrate to a non-relational database (precisely because you do not have SQL in your application code). Look at the use of JDO and JPA in Google's App Engine.
恕我直言。 ORM 是需要的。
它允许您以OOP方式访问数据库，无论是否多个数据库。
IMHO. ORM is need.
It allow you to access database in OOP way, no matter multiple database or not.