
Reply to “What ORMs have taught me: just learn SQL” - numo16
http://weblogs.asp.net/fbouma/reply-to-what-orms-have-taught-me-just-learn-sql
======
webnrrd2k
I don't find this response convincing...

First, in the intro, it sets up a straw man argument -- that a ORM won't fix
your remarkably crappy db or object design. No one expects magic, and I don't
see how it's relevant. However, sometimes people are _given_ remarkably crappy
designs that they have to support, and ORMs make it much more difficult. ORMs
are much better when you can start your db from scratch, but not so good when
you have an inconsistent or legacy system.

I agree with him about the dual schema dangers, though (ie, Objects -> tables
or tables -> Objects doesn't really matter once you have a good abstract
entity model worked out. It's sometimes tough to work one out, though, and I
tend to do it in the DB first)

Transactions in an ORM have been a huge problem, so I pretty much do as much
as possible in the db through stored procedures, combined with whatever
application code necessary to verify everything is moving along as it should.

It seems to me that most developers should learn SQL and databases fairly
well. They are just so common, and it's not all that much trouble. Once you
know how to normalize data and some basic SQL you're well along the way.

ORMs have their place in relatively simple projects, but once code passes a
certain level of complexity then ORMs cause much more pain than they are
worth. It's a classic leaky abstraction -- you end up spending too much time
fighting with the ORM. Debugging SQL through an ORM can be a nightmare, too.

