Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OrmHate

martinfowler.com

Post reply on HN
Print view View original

51–60 of 136 posts

Re: OrmHate

#51

Post by debacle »

mping wrote: post #40
debacle wrote: post #15

Earlier quoted context omitted.

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

Re: OrmHate

#52

Post by zzzeek »

mgkimsal wrote: post #37
brazzy wrote: post #11

Earlier quoted context omitted.

Have you actually read TFA? Fowler's point is that yes, ORMs don't solve all of the really hard mapping problems, but save you a lot of boilerplate on the other 80-90%, and the hallmark of a good ORM is that it allows itself to be bypassed with relatively little hassle for those hard problems (like performance tuning). Also from TFA: what do you suggest using instead?

Come on - how hard is it to write "select id, username, email, nickname, date_registered, pass_hash, first_name, last_name, middle_initial, home_phone, mobile_phone, work_phone from user where username=?" and manually do escaping whenever you want user info? You seem to be suggesting that user.findByUsername('joe') is somehow more worthwhile or usable. It's certainly more noble, because an ORM doesn't solve 100% of a…

copying my answer from virtually the identical commentary made on reddit ("why should I use an ORM when I can just write the SQL?") (not to mention Fowler's article makes this same point pretty clearly):

ORMs do not claim to be "simpler than SQL" and this has nothing to do with the purpose of an ORM. There is nothing that's ultimately "simpler than SQL", if in fact you aim to just write SQL.

The purpose of the ORM is to marshal data between an object-oriented domain model and a relational schema, to translate a wide array of common relational patterns with corresponding domain-model patterns (think foreign key to collections, for example), and to express relational queries in terms of the object model at least to some degree.

All of this is well outside the realm of just "writing SQL queries". The ORM is a tool used to integrate relational databases with an object oriented application layer, and to that degree they make this task a lot less effort than doing it by hand.

Re: OrmHate

#53

Post by davesims »

dasil003 wrote: post #13
RyanMcGreal wrote: post #7

> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. 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. In my admittedly anecdotal experience, I have…

And yet many ORMs such as ActiveRecord let you do this trivially, maintaining as much of it's functionality as you want, such as mapping column types to appropriate pl types. In my experience, even if you had a policy of all queries being written explicitly in SQL by all developers and encapsulating these into your own data access layer, you would still have quite a bit to gain from the well-tested community boilerpl…

This. Use ORMs for what they do well, and move into straight SQL when it makes sense.

Re: OrmHate

#54

Post by zzzeek »

debacle wrote: post #6
zzzeek wrote: post #4

Earlier quoted context omitted.

The core of fowler's article is, "what is the alternative to ORMs?" - and the answer is there isn't much other than rolling your own. This is not at all analogous to PHP where there is an abundance of alternatives to it's mediocre design. PHP isn't hated because of its concept - a "web-based scripting language". It's hated because it's done very poorly. Just like a lot of bad ORMs Fowler refers to.

There is nothing wrong with PHP - it runs multi-billion dollar companies and it is the most ubiquitous language on the web for a reason.

there's a lot wrong with PHP, here's a good place to start: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Re: OrmHate

#55

Post by Ygor »

chris_wot wrote: post #42

I've always wondered what the mathematical basis behind OOP is. I mean, relational databases are grounded in first-order logic and set theory. If there was a mathematical theory that grounds OOP, then I'd love to know because then there may be a way of finding a mathematical basis for ORM. Anyone who wants to provide the answer to this one would be my new best friend :-)

Maybe this can help:

http://reperiendi.wordpress.com/2007/11/03/category-theory-f...

Re: OrmHate

#56

Post by jerf »

mping wrote: post #40
debacle wrote: post #15

Earlier quoted context omitted.

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

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

Re: OrmHate

#57

Post by Daniel_Newby »

RyanMcGreal wrote: post #32
debacle wrote: post #15

Earlier quoted context omitted.

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

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

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.

Re: OrmHate

#58

Post by duggan »

There's some serious miscommunication going on every time this discussion comes up.

A lot of people seem to conflate all data abstractions with the term "ORM" (which has a very specific meaning), therefore assuming everyone who thinks ORMs are a bad idea are arguing against all forms of data abstraction.

This is not the case.

One of the better articles on this: http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

Re: OrmHate

#59

Post by compay »

The single biggest disadvantage of ORM for me is that in exchange for easier programability, they force you to learn a proprietary, arbitrary, ad hoc DSL that is less consistent, more complicated and less powerful than SQL.

Re: OrmHate

#60

Post by anuraj »

I for one never touch an ORM if possible. Coding for SQL in code is not that difficult, but sure it leads to SQL lock in. But you don't expect to change your underlying data model and scheme so often, and if you ever do, you most probably need a complete redesign.
Post reply on HN