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

(Some) ORM haters do get it

revision-zero.org

Post reply on HN
Print view View original

71–80 of 108 posts

Re: (Some) ORM haters do get it

#71

Post by dirtyaura »

debacle wrote: post #12

I don't understand where this ORM 'divide' is coming from. ORMs are powerful, because they let you say less and do more. For 90% of the queries out there, an ORM is fine. SQL is powerful, because you can control and fine-tune your statements. For the remaining 10%, use SQL. Are ORMs bad? No. Can you them for everything? No. The same thing can be said for almost every technology in existence.

I'm running a sales reporting and payroll software written in Django, and it's more like 10% of views benefit from ORM and for 90% views ORM is hindrance and a serious performance hit.

I see ORM vs relational style as a development mindset issue. We have moved using SQLAlchemy Core (not the ORM part) and the difference in development style is stunning: now it's quite easy and more importantly FUN to write performant queries, whereas when we were using Django ORM, it was very easy to write non-performant code and tedious to make it fast.

Re: (Some) ORM haters do get it

#72

Post by mistermann »

fusiongyro wrote: post #55
mistermann wrote: post #45

Earlier quoted context omitted.

To me it sounds like you're talking about the argument of who has the responsibility of applying business rules, the application layer or the database layer - which is another entirely valid argument in itself, but distinctly different than the argument of whether to use an ORM in your application layer or not.

Would Reddit be a good example of this, where they use a relational database as a key/value store, don't use an off-the-shelf ORM and still depend on the application layer for all the business rules? I admit I have no statistics, but it's been my experience that most places choose between a highly OO model + ORM and a highly relational model without.

> it's been my experience that most places choose between a highly OO model + ORM and a highly relational model without.

My experience has always been a highly relational model, ORM or not, and business rules enforced in app layer or DB (or a mix of the two). I've always seen them as distinctly different decisions.

Personally, in the past I was always a "rules in the app layer" guy, because of the many advantages of doing in that way, but as I get older the more difficult but guaranteed correctness of implementing in the database is becoming more appealing (especially if it's not me that has to actually write the code!!)

Re: (Some) ORM haters do get it

#73

Post by pradocchia »

mistermann wrote: post #45
fusiongyro wrote: post #40

Earlier quoted context omitted.

The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost,…

To me it sounds like you're talking about the argument of who has the responsibility of applying business rules, the application layer or the database layer - which is another entirely valid argument in itself, but distinctly different than the argument of whether to use an ORM in your application layer or not.

To a database person, the database is all about business rules: what we recognize as a "thing", what we record about these things, and how they relate to other things. ie, what are the facts about the business, and how do we reason about them?

Any conformant client code then must honor these rules, and oftentimes that means it must re-implement them, which is an acceptable cost if we have decided to use an RBDMS in the first place.

Now it's true, a given database may only implement a subset of all applicable business rules--maybe some fall outside the scope of the database, maybe it's preferable to offload some to a trusted client, maybe the business and database model have drifted apart over time, and no one wan't to overhaul the database model due to all the dependencies involved.

That said, any rules that the database does implement is a good thing, especially those simple rules that can be implemented as constraints. And it's good because then you can program against them, from any client, from any code, inside the database and elsewhere, and you can make guarantees about what possible states the data could be in. This is generally a useful thing.

Re: (Some) ORM haters do get it

#74

Post by recursive »

nsxwolf wrote: post #48

This article is all about RBAR vs. set based operations. It has little to do with ORMs per se. That naive ORM users may tend toward RBAR is beside the point. Go RBAR when it doesn't matter - when it's convenient and you know how it is going to scale ahead of time. A user updating his profile. Creating an order. Go set based the rest of the time - when you're processing a large batch of data for thousands of user acco…

What is RBAR?

Re: (Some) ORM haters do get it

#75

Post by div »

fusiongyro wrote: post #68
jshen wrote: post #61

Earlier quoted context omitted.

"To us, what's most important is the data, so everything else must serve that end" Surely this is a flawed world view!

Let me pitch you this scenario. You run Facebook, and you have all the software and all the data. A catastrophe occurs and you lose everything, and due to a mistake in the way backups were made, you can choose to restore the software or the data, but not both. (Somehow, restoring the software will destroy the data, and restoring the data will destroy the software). Which one do you choose?

Hm, that's a great question, even outside the scope of this ORM context.

I would probably pick the data. It's what can be monetized and it's impossible to regenerate.

Having to recreate the software might even be beneficial in the long term if your engineers are careful enough to avoid second system syndrome.

Re: (Some) ORM haters do get it

#76

Post by [deleted] »

dirtyaura wrote: post #71
debacle wrote: post #12

I don't understand where this ORM 'divide' is coming from. ORMs are powerful, because they let you say less and do more. For 90% of the queries out there, an ORM is fine. SQL is powerful, because you can control and fine-tune your statements. For the remaining 10%, use SQL. Are ORMs bad? No. Can you them for everything? No. The same thing can be said for almost every technology in existence.

I'm running a sales reporting and payroll software written in Django, and it's more like 10% of views benefit from ORM and for 90% views ORM is hindrance and a serious performance hit. I see ORM vs relational style as a development mindset issue. We have moved using SQLAlchemy Core (not the ORM part) and the difference in development style is stunning: now it's quite easy and more importantly FUN to write performant…

[deleted]

Re: (Some) ORM haters do get it

#77

Post by debacle »

dirtyaura wrote: post #71
debacle wrote: post #12

I don't understand where this ORM 'divide' is coming from. ORMs are powerful, because they let you say less and do more. For 90% of the queries out there, an ORM is fine. SQL is powerful, because you can control and fine-tune your statements. For the remaining 10%, use SQL. Are ORMs bad? No. Can you them for everything? No. The same thing can be said for almost every technology in existence.

I'm running a sales reporting and payroll software written in Django, and it's more like 10% of views benefit from ORM and for 90% views ORM is hindrance and a serious performance hit. I see ORM vs relational style as a development mindset issue. We have moved using SQLAlchemy Core (not the ORM part) and the difference in development style is stunning: now it's quite easy and more importantly FUN to write performant…

Yes, I could see that - writing reports is one example of an instance where ORMs are almost entirely useless.

Re: (Some) ORM haters do get it

#78

Post by debacle »

chris_wot wrote: post #56
debacle wrote: post #30

Earlier quoted context omitted.

ORMs don't try and handle anything. People apply them poorly which simply creates bad code. The same can be said of the goto statement, or any number of other things - used improperly, they screw up everything, but in some instances they are necessary and good.

Actually, that's not really true. An ORM will almost always attempt to convert your object access to SQL. It's not always possible to make it work as well as a rewritten query. For instance, sometimes you need to use an EXISTS, or change a join order with a hint, or find a better way of reducing the driving table's rows to get better performance. With an ORM, no matter how much tweaking you do, it is sometimes imposs…

BUT...those are problems that an ORM is not a good tool for. If someone is trying to use an ORM for that, that's the programmer's fault, not the tool's.

Re: (Some) ORM haters do get it

#79

Post by mistermann »

fusiongyro wrote: post #68
jshen wrote: post #61

Earlier quoted context omitted.

"To us, what's most important is the data, so everything else must serve that end" Surely this is a flawed world view!

Let me pitch you this scenario. You run Facebook, and you have all the software and all the data. A catastrophe occurs and you lose everything, and due to a mistake in the way backups were made, you can choose to restore the software or the data, but not both. (Somehow, restoring the software will destroy the data, and restoring the data will destroy the software). Which one do you choose?

Although that makes for an interesting conversation, it is a red herring / strawman / false dichotomy with respect to this discussion.

> To us, what's most important is the data, so everything else must serve that end

To you, yes, and I don't fault you for defending that perspective. But the real master who must be served is maximizing "profitability" while maintaining an acceptable level of risk.

Anyone from either side of this argument who ignores the very real advantages from the other side, or the risks from their own side, are the only ones who are totally wrong. (Which would make the author of the original article the one that is most "wrong" in this discussion, as far as I'm concerned.)

Re: (Some) ORM haters do get it

#80

Post by [deleted] »

fusiongyro wrote: post #68
jshen wrote: post #61

Earlier quoted context omitted.

"To us, what's most important is the data, so everything else must serve that end" Surely this is a flawed world view!

Let me pitch you this scenario. You run Facebook, and you have all the software and all the data. A catastrophe occurs and you lose everything, and due to a mistake in the way backups were made, you can choose to restore the software or the data, but not both. (Somehow, restoring the software will destroy the data, and restoring the data will destroy the software). Which one do you choose?

[deleted]
Post reply on HN