(Some) ORM haters do get it • Hacker News Board

Re: (Some) ORM haters do get it

#41

Post by ajross » Mon, May 14, 2012, 3:54 PM UTC

gbog wrote: post #39

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.

"ORM is fine" 90% or even 100% of the time don't make them right. Thee problem is that OOP is not well defined, it belongs to "soft" science, and relational databases are "hard" science. I have read the article about ORM and Vietnam, in we just have all of the symptoms of impedance mismatch. I have to add that this issue is much deeper than a simple efficiency issue. A perfect db with 100% availability would still no…

Related to your point would be an argument that software engineering is more productive when treated as a "hard" science (which I take to mean something like "rigorous justification of all steps" or "clear derivation from principle").

I don't think that's true at all, as evidenced by pretty much every successful software product ever (including the early relational databases, I should add) but would be curious to see the counterargument.

Re: (Some) ORM haters do get it

#42

Post by pbz » Mon, May 14, 2012, 4:05 PM UTC

superasn wrote: post #25

I think the problem with ORM is that at the end it is only a wrapper over SQL, say like Winzip is for Zip. So while it may look pretty and easy to use, it always has to obey the rules of the host program, and so workarounds such as these have to be invented. On the other hand if somehow ORM was part of the core compiler AND database, then somehow it could be possible that even when you write a for loop on the top and…

That would never work though, at least not in the perfect, non leaky way the author and you would like. When you have a loop, even if the database could somehow understand that loop, you can put anything inside it. You could make a call to an outside service, write to disk, etc. With a single SQL query the database can take it and optimize it since it has a full understanding of its data domain.

Re: (Some) ORM haters do get it

#43

Post by mattmanser » Mon, May 14, 2012, 4:08 PM UTC

fusiongyro wrote: post #40

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.

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

But the truth is the days of DB being king are almost gone.

These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand how to code properly.

Re: (Some) ORM haters do get it

#44

Post by parfe » Mon, May 14, 2012, 4:09 PM UTC

Any system I've worked in that didn't use an ORM still implements an ORM.

Save methods which runs insert or updates. GetAll methods get_by_username, get_by_id, get_by_email, get_recent, get_by_foreign_keyed_object, get_by_other_foreign_keyed_object.

And all those hand coded methods directly tied to the dialect of the db the original developer used.

Using Hibernate I had to write raw SQL for some reporting. I've never written raw SQL in Django (the project I've used django on self select for simplicity).

And using SqlAlchemy/Twisted as a backend for a desktop application I haven't found a need yet, for performance or correctness. I have one query I'm eyeing for an SQL rewrite, but it'll probably be a week of work to make sure it works correctly and I'd rather release this phase than save 30 seconds on a weekly query.

I've reached a point where ORM complaints don't really make all that much sense. The issue seems to be "THe ORM breaks down doing X and Y and Z so I had to hand write SQL!"

But you'd be writing X Y and Z anyway if you weren't using an ORM, so what's the issue?

Re: (Some) ORM haters do get it

#45

Post by mistermann » Mon, May 14, 2012, 4:09 PM UTC

fusiongyro wrote: post #40

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.

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.

Re: (Some) ORM haters do get it

#46

Post by debacle » Mon, May 14, 2012, 4:10 PM UTC

fusiongyro wrote: post #40

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.

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

Your response is long, but altogether too subjective, philosophical, and tautological.

What matters is consistency, usability, and agility. Throwing ORMs out the window will give you as much consistency as you can squeeze out of an SQL server, but will greatly reduce your agility. Using an ORM for everything will greatly increase your agility but will reduce your usability.

As in everything, there is a balance. People who fall on either side of that balance need to back away from the pulpit and rethink their stance.

Re: (Some) ORM haters do get it

#47

Post by chris_wot » Mon, May 14, 2012, 4:17 PM UTC

I agree with a lot of what you he says, however what about the case of getting 10 rows with 20 columns - each column needing a join. The optimizers often go nuts over this sort of thing, as that's 20! combinations the optimizer must iterate over to get a good join order.

Apparently, Postgres has a genetic optimizer that handles this... curious to see if this is an issue or not.

Incidentally, I'd like to say that I loved the author's Relational Basics II at http://www.revision-zero.org/relational-basics-2 I've come to the conclusion that SQL is particularly limited in its application and implementation. I'd love to see a better declarative language for databases!

Re: (Some) ORM haters do get it

#48

Post by nsxwolf » Mon, May 14, 2012, 4:18 PM UTC

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 accounts, offload that work into a stored procedure and call it.

ORM does exactly what it is meant to do, and if you're working with data in an OO model, you're going to be doing ORM, whether you know it or not - you will either pull a decent ORM tool off the shelf, or you WILL be writing your own very bad one.

Re: (Some) ORM haters do get it

#49

Post by mistermann » Mon, May 14, 2012, 4:19 PM UTC

parfe wrote: post #44

Any system I've worked in that didn't use an ORM still implements an ORM. Save methods which runs insert or updates. GetAll methods get_by_username, get_by_id, get_by_email, get_recent, get_by_foreign_keyed_object, get_by_other_foreign_keyed_object. And all those hand coded methods directly tied to the dialect of the db the original developer used. Using Hibernate I had to write raw SQL for some reporting. I've never…

Exactly. Or more explicitly, the anti-ORM argument, to me, consists of: ORM works fine for A through W, but SQL is better for X, Y, Z. So rather than just the common sense solution of writing just X,Y,Z in raw SQL, everything has to be written in raw SQL.

Re: (Some) ORM haters do get it

#50

Post by jakejake » Mon, May 14, 2012, 4:23 PM UTC

As an author of an ORM I can agree with the OP that using them incorrectly can lead to horrible punishment on the database. He seems to be most concerned with the n+1 issue which happens when you loop through objects and another query is performed on each iteration.

If you're going to use an ORM then you absolutely have to learn the mechanics to avoid n+1 queries. Every ORM is a little different, some are easier to tune than others.

I personally favor a basic mapping that the ORM does automatically combined with an advanced mapping that allows you to basically write queries for special purposes and map them to transient objects that don't necessarily exist in your schema. You have to do this for things like aggregate queries or calls that require several joins but only need a couple of columns from each table.

The OP raises some good points but I do think that ORMs can be used properly to great effect.