Home/ Questions/Q 570549
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T13:24:48+00:00

The reason why I ask this is because I need to know whether not

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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:

    • Managing indexes in the RDBMS. Improve as many algorithms as possible from O(n) to O(log2n).
    • Intelligent caching architecture.
    • Horizontal scaling by database partitioning/sharding.
    • Database load-balancing and replication. Read from slave databases where possible, and write to a single master database. Index slaves and masters differently.
    • Supplement the RDBMS with complementary technology, such as Sphinx Search.
    • Vertical scaling by throwing hardware at the problem. Jeff Atwood has commented about this on the StackOverflow podcast.

    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.

    • 0