> Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it.
You're showing a severe bias.
> I have found that ORMs are the most useful for the most trivial queries.
That's really what ORMs are for. Three joins, max. Any more than that and you really can't trust the ORM. It's a computer, after all, not a DBA.
I strongly disagree with this. I'm consulting for a project where I cannot discuss technical decisions about database modelling; sometimes we need to query 20/30 tables or more in a tx, with very complicated mappings 5+ levels deep. If I was to write the sql for this, I'd take 10x the time and it would be wrong anyway.
Of course, this is one end of the spectrum where the ORM just enable me to shoot in the foot faster. I've also worked in the other side of the spectrum where I could use an ORM and generate exactly the sql query I wanted.
At the very least, ORMs can save you substantial time because of typesafe queries (if they are typesafe) and expressiveness (specially on join syntax).
My teacher used to say that you can solve half of your problems with an abstraction layer; I think for lots of cases an ORM does just this.
"If I was to write the sql for this, I'd take 10x the time and it would be wrong anyway."
SQL is the problem here. It's so hard to write reusable, composable fragments of SQL that we've all just internalized the idea that we have to write the query you're referring to from scratch every time, which is a bizarre and annoying intrusion of 1970s software engineering into our 2012 world. You almost certainly have patterns of access you are using, and if you could define those in a more sensible query language, and easily compose them together later, basically DRY out your queries, you might not find this such a daunting prospect, and might not need to use an ORM to paper over this deficiency.
It's SQL that's the real, core problem here, and I mean the language qua query language, not the relational model, not object orientation, not even the impossible mapping thereto, it's that SQL is a terrible, terrible language. We should stop elevating it to the status of One True Query language. If SQL didn't suck so hard it wouldn't be so necessary to try to solve the impossible mapping problem in the first place.
I've done the "kick a design around in my head as I'm driving home" on this problem a few times, and the optimizer is always what ends up stopping me dead. I can create a new query language, I can write the compiler to turn it into an equivalent SQL query, but I have no interest in the monstrosity the language would become if it tried to give you enough control over the resulting SQL to satisfy optimizers. A query language that produces uselessly slow SQL is itself useless, so it's hard to get up the motivation to start a project like this when there's basically no way I can produce something usable.
I guess I shouldn't have made such generalizations about how many joins, and I'll fully admit that I've written a 10+ join query in an ORM and the SQL it generated was just fine.
I'm going to make an argument here, and you might disagree but that's fine:
If you don't understand the purpose of an ORM, you haven't worked on a sufficiently large enough software project or don't fully understand what the definition of an ORM is.
If you need to write a report of any fashion, do not use an ORM. You can help write the report with your ORM of choice, but at some point you need to get down to the language that the database speaks because you're doing the kind of set mathematics that ORMs aren't made for.
BUT, if you need to add a user permission, and you're doing anything other than:
If your object model at some point gets persisted into a database, then you're going to need to write code to (load from/save to) the database. At which point, if it walks like a duck, and quacks like a duck...
>> In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?
1. I disagree with your assertion. Ruby's ActiveRecord has scopes that make it very easy to compose complex queries from pieces; start with a simple query, then conditionally add clauses like where, having, joins, group, order, etc. I'm looking at code right now where mixing and matching clauses like that was crucial. It would have been a nightmare to do in raw SQL.
2. Even if you were right, "least challenging" != "least annoying." Washing clothes is a trivial problem, but I'm glad to have a machine do it. Same for writing the same boilerplate SQL 30 times a day.
You're showing a severe bias.
> I have found that ORMs are the most useful for the most trivial queries.
That's really what ORMs are for. Three joins, max. Any more than that and you really can't trust the ORM. It's a computer, after all, not a DBA.