4 ms·
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/3
by mping 14y ago
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.
- debacle 14y agoI 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.
- jerf 14y ago"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.
- debacle 14y agoI would agree with you. It's impossible to write a query that can both be composable and also use all of the features of the SQL server's optimizer.
- jerf 14y agoI'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.
- nollidge 14y agoI've often felt that SQL was terrible, but I don't know what would be better.
- jules 14y agoRelational algebra or Datalog.
- mping 14y agoInteresting remark. Although I really can't see any other good alternative at the moment.
- lucian1900 14y agoI've found tools like SQLAlchemy do let you compose queries pretty well. I've been told ClojureQL has a similar property.