Databases == PAIN

On Greg’s weblog, Alex Krizhevsky writes:

I’m still having trouble convincing myself that these things offer a distinct advantage over plain-old SQL, at least when we have to write the object definitions by hand. That’s a pain.

ORMs are painful. They’re not a silver bullet, but as I’ve learned over the last 5 years - they’re a hell of a lot better than dealing with raw SQL for one fundamental reason:

Any non-trivial application with a significant degree of database access will eventually be refactored to have a “database” layer. Maybe you don’t have generative select statements, but you almost certainly end up writing methods that accept arguments which will at least fill in the blanks in your WHERE clauses.

Eventually - you grow out of that and you find you need to support a Unit of Work pattern. Then you need proper constraint management. Then you need to port to another database.

You see where this is going. You’ll end up writing your own - probably poorly implemented - ORM layer.

Chances are - you also probably don’t have enough breadth of domain experience with a wide variety of applications. You’ll miss solving the problems that other people have already solved.

So to me - the real question becomes - “when is it a good time to fire myself from this work” ?

The usual answer - at least for myself is - the sooner I can fire myself from building stuff that the end user doesn’t care about, the better.

—

A couple more points:

Just because you can read SQL you’rve typed out doesn’t mean that you really know a lot about the efficiency of that statement. I’ll assert that you really need to measure the performance of a query to really understand what’s going on. Otherwise, you’re just fooling yourself.

Databases may use indexes or ignore indexes without telling you about it. You may never know until you finally sit down and run the query planner to see what’s going on.

On the other hand, with a well designed ORM - you’ll get some nice features including: eager lager loading, arbitrarily complex statements, and the ability to bind those statements to mappers that return objects.

Really - you don’t want to be doing this on your own. This stuff is hard, tedious to get correct and to repeat myself just one more time - your users don’t care about the database library. Just use something that works and will scale up as your app gets more complex.