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

61–70 of 136 posts

Re: OrmHate

#61

Post by debacle »

jerf wrote: post #56
mping wrote: post #40

Earlier quoted context omitted.

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

Re: OrmHate

#62

Post by GFischer »

mattmanser wrote: post #30
GFischer wrote: post #14

Earlier quoted context omitted.

Please do come and have a talk with my (pointy-haired style) boss :) . I take it you think stored procedures are generally good (at least that's what I think). But some people still believe that they'll migrate database architecture or some such. Also, some ORM's aren't fit for the task and give a bad name (Microsoft's Entity Framework v1 was especially horrible) I'm definitely out of touch and I spend way too much t…

Re: SPs, no, I meant people used to say all your data access should be through SPs, which seemed to turn about 5-7 years ago as the general consensus moved to parametrized queries and freedom from DBAs overseeing your changes. I haven't seen anyone say that in a long time now. I used to use them for complicated TSQL and helper functions, like some crazy recursive tree building stuff, but these days I haven't actually…

Heh, I'm probably 15 years behind then :) . Thank you for the reply :)

I strongly dislike writing "strings with sql" inside my code, though I do use parametrized queries these days.

I do appreciate freedom from DBAs as a feature :) but I have access to my stored procedures these days (though I don't know for how much longer).

I work for an insurance company with an awful legacy database structure, with mnemotechnic table names like S0001... to S99999, and disregard for naming conventions or even normalization sometimes. It's not making me a better developer :( unless learning by bad examples counts.

Re: OrmHate

#63

Post by wmil »

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.

It's success is largely due to it having the correct execution model. The request based execution environment makes iterative development quick and easy.

However there are plenty of bad ideas in the language itself.

Re: OrmHate

#64

Post by wiradikusuma »

compay wrote: post #59

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.

It depends on what "proprietary" means. In Java, ORM is pretty much standardized with JDO/JPA.

Re: OrmHate

#65

Post by latch »

polyfractal wrote: post #29
latch wrote: post #21

Surprised by the pro-ORM comments so far. My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model fits the data model. Graphs are a good example, but Redis is a better one. When your intention fits a Redis data structure, it's just programming bliss - a few lines of explicit and simple code. The only way I can use a relational database now is with Sequel.

I'm confused by your statement. When your data fits the tool that was designed to work with that data...everything is great? Isn't that the point of using the right tool for the right job?

What's confusing? For years...decades...developers have been taking a one-size-fits-all approach to data storage - relational databases.

Now that we are starting to make use of more specialized tools, we're starting to go back and question (or hate) our past approach.

Re: OrmHate

#66

Post by ap22213 »

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…

In some ways, I agree with you. SQL is part of the problem. But, correctly structuring data is generally very hard, time consuming, has diminishing returns, and adds maintenance issues that never go away.

I've seen teams spend months up front trying to craft a perfect schema, only to see it demolished when a non-obvious edge case appears. I've also seen teams become over burdened with schema and data maintenance, that it takes up 20-30% of their time. That's not to say that you're not right, but sometimes ORMs are just the more pragmatic answer to get a team through the first 4-5 iterations (or even longer).

And, sometimes path-independence is important. But, often, the database just ends up being coupled with the application anyway. At least that's my experience.

Re: OrmHate

#67

Post by krig »

brazzy wrote: post #11
krig wrote: post #3

"You have a relational mapping problem. 'I know', you say. 'I'll use an ORM.' You now have two problems." That just about sums up my experience with ORMs. Of course, like all things in the real world, experiences vary. However, I do think that generally, ORMs solve none of the difficult relational mapping problems and adds another layer of abstraction that complicates things like performance tuning to the point of ne…

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?

I'll try to clarify what I mean, since my reply to the other post is somewhat confused. I should read more carefully before posting. Anyway.

First of all, is your data suitable for storage in a relational database?

If not, if you end up having to do tons of joins and every table has references to other tables, something like Redis is probably a better fit - I'd move away from ORM/relational at that point.

If it is, then what does using an ORM buy you? Simple queries are simple to write and maintain, so in my experience you don't gain much there. More complicated queries are not handled well by any ORM I've seen, so there you'll want to write them in a relational language anyway.

So, at least the situations I've had come up have both resulted in moving away from the ORM, either to a non-relational database or to keep the data in a relational-friendly format. A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping. For example: you have an inefficient join. Using an ORM, you'll be solving this problem indirectly either by massaging the ORM or bypassing it entirely. If your join is directly expressed in SQL, you solve the problem by modifying the join. There's no additional headache involving figuring out how the object model turns into tables and queries.

Re: OrmHate

#68

Post by RyanMcGreal »

lucian1900 wrote: post #41
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 tools that help one write SQL queries more easily (like SQLAlchemy) are so much more useful than ORMs. The fact that SQLAlchemy also has an ORM built on top of those tools only sweetens the deal.

Heh. I use SQLAlchemy, but I don't use the associated ORM.

Re: OrmHate

#69

Post by ken »

> In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that worked out.

Maybe I'm too young (or too old) because I don't know what he is suggesting here. I've used an object database on a large commercial project, and it was a dream: everything I like about ORMs, and none of the drawbacks.

My impression of OODBs, therefore, is that they were a technical success, but a commercial (and open-source) failure. But I don't think that's what Martin is suggesting. Can someone explain what "we all know" about database history here?

Re: OrmHate

#70

Post by vegas »

I think it's basically the O part. In theory, one might have a delightful ontology of object oriented code, like Animal->Mammal->Cow , but in reality you often have something much more like

CompanyNamePersistentObjectBaseClass->Entity->ExtendedPersistentEntity->CacheFactory->Entity(but in a different package)->NeedToAddAPropertyForJustThisReleaseIPromiseThisClassIsGoingAway->IdAddThisToTheBaseClassButIReallyNeedToRelease->Shape->Triangle->XYCoordinates

and then somebody wants to cache these things in hibernate.

Post reply on HN