OrmHate • Hacker News Board

Re: OrmHate

#41

Post by lucian1900 » Tue, Jun 26, 2012, 3:00 PM UTC

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.

Re: OrmHate

#42

Post by chris_wot » Tue, Jun 26, 2012, 3:03 PM UTC

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 :-)

Re: OrmHate

#43

Post by debacle » Tue, Jun 26, 2012, 3:04 PM UTC

Cloven wrote: post #26

debacle wrote: post #18

Earlier quoted context omitted.

I don't think Facebook or Yahoo chose PHP because it was easy to write.

you are incorrect.

Yahoo's rationale for choosing PHP:

"The short development cycles needed to stay ahead of the competition demand a web-centric scripting language that is easy to maintain and update."

http://public.yahoo.com/bfrance/radwin/talks/yahoo-phpcon200...

They didn't choose Python, or Ruby, or Java, because none of those languages are as expressive or shut-up-and-get-out-of-my-way as PHP. Just because a high schooler can write PHP doesn't mean it's a toy not also meant for world class engineers.

Re: OrmHate

#44

Post by papsosouid » Tue, Jun 26, 2012, 3:04 PM UTC

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.

Just because PHP doesn't 100% doom you to failure, doesn't mean there is "nothing wrong with it".

Re: OrmHate

#45

Post by mechanical_fish » Tue, Jun 26, 2012, 3:05 PM UTC

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.

From the article:

I think NoSQL is technology to be taken very seriously… But even so it only works when the fit between the application model and the NoSQL data model is good. Not all problems are technically suitable for a NoSQL database. And of course there are many situations where you're stuck with a relational model anyway. Maybe it's a corporate standard that you can't jump over, maybe you can't persuade your colleagues to accept the risks of an immature technology. In this case you can't avoid the mapping problem.

Re: OrmHate

#46

Post by Spooky23 » Tue, Jun 26, 2012, 3:06 PM UTC

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. For anything complicated, I find it easier to drop into SQL and write the query directly

As a recovering DBA, I want to jump out of my seat and say "Yes, exactly!"

In many situations, "simple" queries can easily cover 90% of what you actually need, and simple queries are often an order of magnitude less expensive than even modestly complicated ones.

If your devs are in the habit of writing lots of SQL, they'll often decide to do things like write one complex query to avoid the need for a few trivial queries. From a developer point of view, that makes sense, but the result is that you end up chewing lots of database resources. Databases tend to become scarce resources quickly, and it's usually very expensive to scale up.

In my previous experience, the ORM helped reduce needlessly complex queries, and freed up resources on the DBA side of the house to help optimize the complex stuff that needed to be there.

Granted, I was a DBA a long time ago, and resources were far less plentiful back in the good old days. But I think this is still relevant whenever you get into "big" databases.

Re: OrmHate

#47

Post by krig » Tue, Jun 26, 2012, 3:06 PM UTC

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…

You pretty much nailed what I was going to say. Yeah, I found it a bit strange that the only alternative to using an ORM that the author could imagine was to roll your own? What's the problem with using SQL directly?

To answer the grandparent: I did read TFA, and I don't buy it. His claim that a good ORM makes 90% easier and gets out of the way of the remaining 10% doesn't match my experience with any ORM at least. Perhaps I'm wrong! All I'm saying is that from what I can tell, using an ORM buys you nothing worth buying.

edit: Ha, you're being sarcastic. No, I'm serious. Are you saying that using an ORM solves escaping problems? I honestly have never connected those two. That to me is a problem calling for a set of escaping/unescaping functions, not an object-relational mapping. To each their own...

Re: OrmHate

#48

Post by mindcrime » Tue, Jun 26, 2012, 3:07 PM UTC

jonstjohn wrote: post #22

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…

Or maybe people expect to interact exclusively through the ORM and when they have to do something more complex, conclude that the ORM is useless. When using an ORM increases the complexity of the code substantially over direct SQL, I'll usually switch to more comprehensible SQL.

Well, at least in the case of Hibernate, it's easy enough to drop down to native SQL when you need it (although you obviously risk giving up database independence) and you can still keep the OOP "feel" by defining query post converters and what-not.

The points made above about "don't use ORM for reports" aside (a point I strongly agree with, btw), I've found Hibernate makes my life a lot simpler and rarely gets in the way or fails to do what I need it to do. But I do occasionally create a native query to deal with some edge case or whatever.

Re: OrmHate

#49

Post by judofyr » Tue, Jun 26, 2012, 3:07 PM UTC

phillmv wrote: post #35

columbo wrote: post #12

def user = User.findById(25) return user.getLocation().getAddress().getState() What happened during that execution? Was that 1 query or 50? Would it have been better to write a specific sql statement? To me, this describes the biggest challenges with using or not using ORMs. I don't think there is an easy answer.

>I don't think there is an easy answer. Uhm, ActiveRecord at least will print the SQL it generated. If you think it's inefficient, you can just… write your own sql that maps out to that query. With Arel/scopes, they're also composable and lazy loaded. What's not to like?

I find that the opposite way is way harder to debug: I see that a controller causes a bunch of SQL queries, but where do they come from? In the view? In a helper? In another library within the app?

Re: OrmHate

#50

Post by davesims » Tue, Jun 26, 2012, 3:09 PM UTC

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 joins are trivial as well, and can be abstracted away, and a lot of those queries end up being optimized according to known SQL patterns for the common use cases, so you can avoid n+1 and so forth. For these work-a-day queries, ORMs work just fine.

That said, there are tons of situations where ORMs make no sense at all, like complex migrations, large OLAP-style analytic queries, etc. For these, it's important to keep your SQL chops up and know the pitfalls. So, I use ORMs where they work well, and drop into SQL all the time where they don't.

The trick, as with most things, is finding the right balance: don't try to abstract away complex, singular use cases, but also don't duplicate trivial code all over your code base where the ORM has done the work for you.