My view on ORMs

July 18, 2011

Via Hacker News, I recently read ORM's hidden cost. As you might guess, I have an opinion on this.

First off, I agree with the article; ORMs have problems. Among other things that the article talks about, there are fundamental mismatches between the object oriented approach and the SQL approach to a problem. But ultimately the issues about ORMs are a lot like the SQL hairshirt issues: they matter in theory but they do not matter in practice to most people.

Despite all of these issues, ORMs work great at a small size and a small size is where almost all web applications live. Private and internal web apps are almost invariably small, and many public web apps will never grow very big. What matters in this domain is fast and easy development, which ORMs deliver handily because they give you a database that you don't have to think about or learn.

(Many people in this area would be just as happy with an object store that they could query. Really, that's what they're using SQL for.)

If your app or database gets big, this may not work any more and you'll need to get familiar with your actual database (which includes going to the SQL level). But if your app gets big you'll probably have to deal with any number of issues anyways, because big websites are fundamentally different from small websites; you'll get to care about load balancing, front end caches, structuring your HTML and CSS and JavaScript for fast loading, and all sorts of issues in addition to efficient use of your database.

(You can worry about these issues in advance if you want to, and I've done so sometimes for web applications (DWiki is one example). But it will probably slow down your development unless you're pretty familiar with the easy best practices in this area, familiar enough to do them by reflex.)

This implies that the first thing you should do when you're thinking about using an ORM is estimate how big a database and how active a web app you're likely to wind up with. Of course you should be doing that anyways, because it'll tell you how much you have to care about all of the SQL hairshirt issues.

Written on 18 July 2011.
« Another reason to reject spam at SMTP time: as a signal
Thinking about when SQL normalization can improve performance »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jul 18 00:27:41 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.