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

81–90 of 136 posts

Re: OrmHate

#81

Post by j45 »

My why is more of a feeling/observation/theory so please feel free to share your thoughts and feelings:

Some developers hate, and are almost threatened when something fancy and complex they might do is trivialized, thereby trivializing them.

There is no question that something like ORM makes some things easier, and other things harder. It applies equally well to SQL and which flavor of database you end up using, or whether you're using ActiveRecord, etc., or not.

I would hope developers who find something that frees to solve user problems instead of technology problems would be a good thing, but maybe it's just me.

Re: OrmHate

#82

Post by jakejake »

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…

That's exactly how I feel, in fact I was inspired to write an article about it when this topic came up on HN a few weeks ago http://verysimple.com/2012/05/14/re-orm-haters-in-defense-of...

As an ORM author I may be a bit biased, but I really think that, like all things, ORMs are a tool that can be used or abused. That's no reason to throw them out. It must have snuck up on me that there was even an anti-ORM thing happening!

Re: OrmHate

#83

Post by debacle »

Philadelphia wrote: post #76
debacle wrote: post #39

Earlier quoted context omitted.

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

But that doesn't require or imply an ORM. That's just a matter of having an object model.

If you have a database, any object model is at some level an ORM.

Re: OrmHate

#84

Post by einhverfr »

I think the hate comes from two sides:

1) Relational folks who feel that ORMs don't really enable good relational design, and

2) OO folks who feel that ORM's cause a lot of headache regarding relational to operation data structure conversion.

The folks in camp 1 are usually absolutely right. Most ORMs encourage the developer to design the database around the ORM which has to be an antipattern when it comes to relational systems. This isn't always the case. DBIx::Class has done some awesome work on some things like composite primary keys and the like. But generally in most cases it is true.

On the OO side I am less convinced of the costs. So my complaints come from the relational side. Yes object to operational data structure mapping is hard to automate, and it's even harder to automate well. So maybe we shouldn't try. Maybe ORM's should be disregarded in favor of ways of designing the data so that abstractions occur at different points.

In the LedgerSMB project we decided to use stored procedures to accomplish this abstraction. We don't put "all the logic" in the database, far from it. But database operations go through the stored procedures, and these are often well tuned for performance (or as well tuned as they can be). The stored procedures thus create an API for addressing relational data, and this allows an abstraction layer to be formed which maps these into object methods. We'll probably extend this further in the future to tie object properties to complex database types, but we haven't decided the best way to do this yet.

ORMs get a lot of hate because they tackle a very difficult problem and consequently tend to produce results that are unsatisfactory particularly to db folks. They are the product of app designers looking at the db, more often than not, rather than db designers looking at the app.

Re: OrmHate

#85

Post by alex_stoddard »

ef4 wrote: post #38

I think a lot of the frustration with relational databases in general comes from a misunderstanding. People conflate "relational" with "SQL", because of the historical accident that SQL is the most popular way to query relational data. Then when SQL isn't a good fit for their problem, they think relational is not a good fit for their problem, which is almost certainly not true. The original motivation for relational…

Can you suggest any good references for alternatives to SQL or a more general discussion of path independent data access? My background is such that practically "relational" and "uses SQL" are wholly conflated. I would be very interested to get a broader view. Does datalog fit somewhere in the discussion?

Re: OrmHate

#86

Post by bitdiffusion »

Adding to some of the anti-orm sentiment above: I always find that orm's are trying to solve a problem that doesn't really exist. The proportion of time (and therefore cost) spent on a project writing SQL is orders of magnitude less than time spent on things like performance, scalability, user-experience, testing etc. You might have something that only maps data from your results into your language of choice but, again, if small, slightly repetitive tasks like this are affecting your ability to deliver your software, you have bigger problems.

Sure - database design is important - but that you have to do that regardless.

Re: OrmHate

#87

Post by einhverfr »

mindcrime wrote: post #8

Because people are scared of things they don't understand? Or because they had one bad experience, years ago, with some home-grown crappy ORM, and now they assume all ORMs are bad? The reasons are legion... The second of those is what I saw at my last job. The tech-lead / architect guy was vehemently anti-ORM... because a previous group (at the same company) had rolled their own ORM in Jython and embedded it into the…

Let's define a good ORM though.

A good ORM should be able to handle a database designed for a different application, normalized to 5NF or BCNF, using composite primary keys, composite foreign keys, and other solid db design concepts, and be able to reliably generate queries to bridge the gap, and should do so where sets of objects are required in a way that does not unduly burden the database with small queries that could be consolidated.

That's a hard problem. There are some ORMs that come pretty darned close if not there. Many more, in my experience fall well short.

Re: OrmHate

#88

Post by jerf »

debacle wrote: post #61
jerf wrote: post #56

Earlier quoted context omitted.

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

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

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.

Re: OrmHate

#89

Post by crazygringo »

davesims wrote: post #50
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…

> In my admittedly anecdotal experience, I have found that ORMs are the most useful for the most trivial queries. True, but 'trivial queries' generally cover the majority of use cases within your average CRUD application, and that's exactly why ORMs are useful -- you don't end up re-typing 'select bar from fu where id = 1' or 'select * from fu, bar where fu.bar_id = bar.id' etc., etc. Beyond that, most of the common…

But ORM's don't actually help for the trivial queries.

I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill.

As for the common joins, in my experience they rarely are that trivial. Sometimes it's a left join, sometimes an inner join. Sometimes there's a limit or not. Sometimes there's an aggregate function.

If you find yourself writing the same query structure 20 times, then create a function for it. But I've never found that to be the case in projects I work on.

I just personally find that ORM's are total overkill in the situations where they can be usefully applied. So the disdain for them kind of makes sense.

Re: OrmHate

#90

Post by norkakn »

einhverfr wrote: post #87
mindcrime wrote: post #8

Because people are scared of things they don't understand? Or because they had one bad experience, years ago, with some home-grown crappy ORM, and now they assume all ORMs are bad? The reasons are legion... The second of those is what I saw at my last job. The tech-lead / architect guy was vehemently anti-ORM... because a previous group (at the same company) had rolled their own ORM in Jython and embedded it into the…

Let's define a good ORM though. A good ORM should be able to handle a database designed for a different application, normalized to 5NF or BCNF, using composite primary keys, composite foreign keys, and other solid db design concepts, and be able to reliably generate queries to bridge the gap, and should do so where sets of objects are required in a way that does not unduly burden the database with small queries that…

What ones do you like? The Django ORM makes me want to vomit every day or so.
Post reply on HN