Why ORM?

Why ORM (Object-Relational-Mapping)?

You are an idiot!

I am getting sick and tired of having this discussion. You think you know something about how things work, but you're not facing the facts. If you honestly believe that using a completely procedural approach to database programming is a good idea, even in a web-based system, you are absolutely wrong! If you think that scalability issues when hitting 100,000 users has anything to do with what database layer you're using to serve a simple page, you are absolutely wrong! Let me break it down.

Scalability Concerns

High number of records

A page that will serve a high number of records in a single load, now or in the future, must be designed as such. It is not a complicated task to understand that a page may be used to view 25+ records, at any given time. If this is the case, very simple standard approaches should be used to solve the problem. Pagination is your solution. The page will scale as well as can be expected, and will not run into load issues (large amount of html data transfer), and certainly will not have memory issues, that arise simply because of the technology being used to hold data.

High number of users

This is simply a hardware concern. If your system expects very large numbers of users, a page that loads one record, but is hit 100,000 times a second, will have scalability issues on the environmental side, not the software side!

Batch processes

Any process that will do heavy lifting and operate on high numbers of records, without the use of block processes and where the concept of pagination does not apply, scalability will be of concern. In these cases, the high learning curve of using an ORM versus procedural approaches will come into play. The programmer simply needs to understand how to bypass the ORM in order to use procedural approaches, and the batch process operating on hundreds or thousands of records will perform fine. Alternatively, you can hydrate objects one at a time, and discard them once used. This will scale your memory footprint much better, and will likely make moot the issue of time scalability for hydrating those objects.

Why does a batch process usually scale badly in an ORM based system? The process of loading thousands of hydrated objects into memory suffers from the law of diminishing returns. You get less benefit for more work performed, and as memory gets eaten up holding all the objects in memory, the process slows down.

Why doesn't this concern come into play with high numbers of users, and low numbers of records? Because a request serving one record will load an object, use it, and discard it just as quickly as the request can be processed. The only scalability concern you will face, as discussed above, is hardware and environmental scalability. This leads us to the conclusion (even without the need for benchmarking, which has been done, BTW) that discarding objects and allowing for memory management of the PL to take its course, will allow an ORM to be used in most situations with only minor adjustments to the approach and tactics.

Conclusion

Using an ORM has astronomical benefits to code organization and programmatic power in systems, including web-based ones. Forcing procedural programming to be used in web-based systems will destroy your organizational power, making your code a complete mess, and only gains you the ability to ignore learning how to use an ORM. You will not have a system that is any more scalable than the system written by a properly versed ORM programmer. Comparative analysis in all other areas of these same systems will indicate that the ORM based system kicks your programs @^%$*, so shut up, idiot!