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

21–30 of 108 posts

Re: (Some) ORM haters do get it

#21

Post by mistermann »

sgift wrote: post #7
mistermann wrote: post #4

Can anyone point out the coup de grâce the author seems to think he has arrived at? He points out some (well known) ways that ORM's can be used inneficiently, and acknowledges the techniques that have been developed to work around these, but then seems to conclude that he has proven once and for all that ORM's are bad. I totally missed the connection on that part. Is it that SQL is better in dealing with sets than an…

The connection (according to the author as far as I've understood him) is: "All the techniques that have been developed to work around the inefficiencies of ORMs are just reinventing the wheel. The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational)."

> The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational)

(This is to OP rather than you)

Well if that's the argument he's making, one example I can think of, in the case of an extremely complex update, while it always can be done in pure SQL, it is much easier to logically code using an ORM, perhaps even using individuals rather than sets (the horror). And while this implementation might execute slower (.1 second vs .01 second), it is vastly simpler to read and refactor without screwing something up (ie: economically cheaper), and as for the performance argument, it only needs to be fast enough.

Re: (Some) ORM haters do get it

#22

Post by knieveltech »

stcredzero wrote: post #13
sgift wrote: post #7

Earlier quoted context omitted.

The connection (according to the author as far as I've understood him) is: "All the techniques that have been developed to work around the inefficiencies of ORMs are just reinventing the wheel. The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational)."

your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational). What if it's better structurally for the program as a whole to think about individuals?

That seems to be the question at the heart of the debate surrounding ORM's and OO in general and the debate rages on...

Re: (Some) ORM haters do get it

#23

Post by nknight »

FuzzyDunlop wrote: post #10

I'm well open to correction on this, since I've not much of a clue, but with all this ORM back-and-forth, and relational databases, why do we not see more usage of graph databases?[1] From the wiki, it says they map more directly to OO applications. Is there a reason relational databases are still used by default? [1] http://en.wikipedia.org/wiki/Graph_database

Inertia, accidents of history. Relational databases had obviously-useful properties at critical points in the history of mass commercial adoption of computing. As a practical, real-world matter, "object-oriented programming" barely existed during the rise of relational in the 70s, making the practical problems caused by the impedance mismatch either non-obvious or seemingly unimportant.

As a result, huge investments were made in advancing relational databases, and other forms have languished. Today, relational maintains the substantial advantages of maturity and installed base. Performance, reliability, general polish, ease of access to support/tutorials/other literature, and general status as "the way things are done".

Re: (Some) ORM haters do get it

#24

Post by biafra »

FuzzyDunlop wrote: post #10

I'm well open to correction on this, since I've not much of a clue, but with all this ORM back-and-forth, and relational databases, why do we not see more usage of graph databases?[1] From the wiki, it says they map more directly to OO applications. Is there a reason relational databases are still used by default? [1] http://en.wikipedia.org/wiki/Graph_database

Sometimes the reason is that operations is used to it.

Re: (Some) ORM haters do get it

#25

Post by superasn »

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 have an if conditions inside the block, or perform a join, the compiler understands it and pre-compiles your code without needing such workarounds (as there aren't two separate layers to join). So you would treat objects and objects and never have to worry about how the wrapper is being generated or what kind of indexes or queries it will run finally. I'm not an expert at compilers though but for strictly typed languages it could be possible.

Re: (Some) ORM haters do get it

#26

Post by lloeki »

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.

> ORMs are powerful, because they let you say less and do more

To me this is a bonus. The real deal is that ORMs allow you to write queries as "first-class" components of the language, hence benefiting from language features such as type checks, duck-typing, factoring, static analysis even, and more.

Compare this to stitching strings (however parametrized they are) and manually coercing your object values to strings.

This is where, IMHO, ORMs like ActiveRecord and Arel shine, as they give you access to each building block (form connection.execute to .quoted_table_name to .to_sql) so that you can place yourself at whatever level of abstraction between the two worlds you may need.

Re: (Some) ORM haters do get it

#27

Post by mckoss »

scotty79 wrote: post #18

For easiest things SQL is cumbersome. Getting single row by primary key which is 90% of access is overly verbose in SQL so ORM wins. For slightly more complicated cases SQL is much faster and easy to write so people who have to increment field in all rows that satisfy simple condition go: "ORM sucks". But for more complicated cases like trimming data tree in some places SQL quickly becomes too much of a puzzle for mo…

I think this is the motivation behind .Net Linq - bringing the relational query semantics into the language.

http://msdn.microsoft.com/en-us/library/bb308959.aspx

Re: (Some) ORM haters do get it

#28

Post by Retric »

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.

IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner query.

Still, ORM's seem to be getting better Linq to Entity Framework seems to work much better than a lot of the old ORM's I have used.

Re: (Some) ORM haters do get it

#29

Post by asolove »

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 agree that the 'divide' is overstated. But the author does mention one frequent problem: when you begin a project in an ORM, you may begin to depend on validation or update callbacks that get triggered by the ORM. Later, if you discover queries that need to be written manually, you will first likely forget these rules, then have a hard time translating them into SQL, and then have an enormous, permanent headache keeping the two in sync.

Re: (Some) ORM haters do get it

#30

Post by debacle »

Retric wrote: post #28
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.

IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner qu…

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.

Post reply on HN