4 ms·

> 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. Yo

by debacle 14y ago

> 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.

RyanMcGreal 14y ago
In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?
- debacle 14y ago
  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: $user->addPermission( Permissions->get( 'CAN_EAT_CAKE' ) ) you're doing something wrong.
  - Philadelphia 14y ago
    But that doesn't require or imply an ORM. That's just a matter of having an object model.
    - debacle 14y ago
      If you have a database, any object model is at some level an ORM.
    - stevenwei 14y ago
      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...
- Daniel_Newby 14y ago
  Because most tasks are simple. If you need to write SQL to put the three most recent blog postings on the company homepage, you're doing it wrong.
- nathan_long 14y ago
  >> 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.
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 ago
  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.
- 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 ago

by debacle 14y ago

RyanMcGreal 14y ago

In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?

debacle 14y ago
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: $user->addPermission( Permissions->get( 'CAN_EAT_CAKE' ) ) you're doing something wrong.
- Philadelphia 14y ago
  But that doesn't require or imply an ORM. That's just a matter of having an object model.
  - debacle 14y ago
    If you have a database, any object model is at some level an ORM.
  - stevenwei 14y ago
    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...
Daniel_Newby 14y ago
Because most tasks are simple. If you need to write SQL to put the three most recent blog postings on the company homepage, you're doing it wrong.
nathan_long 14y ago
>> 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.

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 ago
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.
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 ago