Meanwhile, the people who are taking the time to learn about and use guns are dominating the world.
Any developer worth his salt will understand how to do SQL Statements to get back the right dataset or perform the correct updates. Harping on the benefits of an ORM is a bright red flag in my book, because none of them are better than the power, performance, and flexibility of actually understanding SQL. If you concentrate on learning the ORM, then you are learning yourself into a box and won't even know that there are great things outside it if you had only spent the time to learn SQL.
Using SQL is great except what do you define as 'SQL'. Is it MySQL, Oracle or Postgres? How do I migrate between them? Forget data migration, I'm just talking about the data model and constraints. Today I run my app on MySQL but tomorrow the environment will demand Oracle.
I have an app that can run on any database that Hibernate supports with zero code changes and 1 line in a config file including my data constraints.
1) performance matters immensely to user experience and I can hand write much better SQL than any ORM I have seen can generate. Additionally I find it easier to predict how well my SQL will perform than to predict how the SQL generated by my ORM will perform.
2) I will likely never switch databases during the lifetime of my company and so switching SQL dialects is not a problem I face.
3) There is an impedance mismatch between tabular data stored in databases and object graphs that most ORMs represent.
4) The specifics of every ORM I've tried always left something to be desired. Hibernate was wicked complicated. Django didn't support multiple databases, SQLAlchemy was error-prone. I'm sure these specifics will get fixed over time, but for me they've just provided further disincentive.
At my current position, we're using entirely hand-coded SQL. It's been a real pain, particularly when trying to fetch large graphs, or when changing the schema.
I read articles like this and wonder if I'm missing something about SQL. I repeatedly find myself writing a whole lot of joins, and writing a tedious converter to map it to something the front end deals with. When I get sick of that and don't care about performance, I do a query for each table. Neither of those seems like the right solution.
It also depends on the ORM you use. At my last full-time gig, a manager became persuaded that the ORM should be used literally _everywhere_. They gutted the stored procs I had written and replaced it all with CakePHP ORM. The result is a program that takes twenty seconds minimum to generate a page; some loadtimes would extend over three minutes.
Cake's ORM is not impressive as far as I am concerned and it's quite slow; if that's the ORM you're using, I think you're better off using SQL almost everywhere. SQLAlchemy seems to have good, tunable performance, though I've also encountered more than my share of strange errors and anomalies with it.
The other downside is that in most cases, it's a _lot_ of work to learn the specific syntax associated with an ORM well enough to allow one to perform a complex query. Many ORMs barely support complex or important DB operations, yet they have adherents who demand insane compliance with ORM implementation.
Even ORMs that are touted as "simple" or "easy" are usually not simple or easy, and of course, the people involved in those ORMs get really, really pissed off if you suggest that docs should improve or errors shouldn't happen as often or whatever.
It's just about getting a programmer with good judgment. Some tasks would benefit from a good, tunable ORM. Many wouldn't. As far as you've written in an ORM, converting between DB engines is that much less work, so it's worth it sometimes. You just have to be sane about it and I think it all ends up okay.
One point that I do think makes sense is where he says "just use flat files". Not that I'd actually advocate that, but if you're going to completely paper over the set-oriented nature of your data store, why not use a "NoSQL" (key/value) database and be done with it.
On the whole Hibernate is awesome. Yes, it has it's warts and it's very complex sometimes but once you make it a part of your infrastructure it's fantastically good. Using Hibernate with sane session management and second level caching gives on the average much better performance than would otherwise get on of hand written SQL. A good hibernate caching strategy can keep you from hitting the database at all and the best part is you just turn it on and go. If you need more performance you can use views and stored procedures for the maybe 1% of cases that can benefit from them.
Lazy initialization is a godsend for complex object graphs and HQL makes complex joins extremely readable and a breeze to write. . The biggest knock I have on Hibernate is that it's so easy to use poorly. No matter how much documentation is on the Hibernate website people insist on using it poorly.
Perhaps its the inevitable corporate association of an RDBM that lends the subject an unattractive image in the mind (as opposed to a sexy new language, framework, or paradigm)? I am frankly at a loss to explain this to myself, given that the theory, technology, and applications of the subject are certainly quite interesting and challenging!
