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

101–108 of 108 posts

Re: (Some) ORM haters do get it

#101

Post by j-kidd »

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

> We're sort of destined to hate ORM, because the people who love databases aren't going to love ORM no matter what, and people who hate databases will resent how much effort they require to use properly.

Speak for yourself. I love databases (note the plural form) and love ORM. ORM is a godsend for developing application that has to work against different databases (postgresql, mssql, db2, etc).

Re: (Some) ORM haters do get it

#102

Post by gbog »

ajross wrote: post #41
gbog wrote: post #39

Earlier quoted context omitted.

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

Software is a complex beast with multiple aspects. The UI design can Bree taken seriously but is no hard science. Many interesting parts just can't relate to hard science, even where you have algorithms. But when handling facts data you have the possibility to ground yourself on hard science, and should. It would be a stupid crime to build a tower without grounding what can be on maths and physics, no?

Re: (Some) ORM haters do get it

#103

Post by nahname »

nupark2 wrote: post #90
nahname wrote: post #36

Earlier quoted context omitted.

Which is creating a false dichotomy. Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM. There is a really interesting post about how writing that code is literally stealing from your clients. I tend to agree. http://ayende.com/blog/3712/stealing-from-your-client

> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM. This is not true. At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database. This is n…

"At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model."

...and that is where you have just created an ORM. You don't need a library to be using an ORM. Change 'extract' to 'map' and the meaning is the same.

Re: (Some) ORM haters do get it

#104

Post by gbog »

romaniv wrote: post #83
gbog wrote: post #39

Earlier quoted context omitted.

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

Set theory is hard science. On the other hand, a grapevine of stored procedures with no code reuse beyond copy-paste aren't any kind of science. I'm not even sure they are any kind of engineering.

You are raising an interesting issue here: does DRY principle apply in db dev. Not sure. Db dev its closer to configuration. Anyway I won't advocate too put all the logic in the database, so I won't get a grape wine, maybe just a fruit plateau, with some duplication but not to much.

Re: (Some) ORM haters do get it

#105

Post by nupark2 »

nahname wrote: post #103
nupark2 wrote: post #90

Earlier quoted context omitted.

> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM. This is not true. At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database. This is n…

"At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model." ...and that is where you have just created an ORM. You don't need a library to be using an ORM. Change 'extract' to 'map' and the meaning is the same.

No, you haven't. If your in-memory application model mirrors your database model, you're probably doing it wrong; either your application model is poor, or your database model is.

Re: (Some) ORM haters do get it

#106

Post by nupark2 »

drumdance wrote: post #93
nupark2 wrote: post #90

Earlier quoted context omitted.

> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM. This is not true. At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database. This is n…

I don't see how ORM forces your hand to be a direct mapping of the database. To me the benefit of ORM is that, most of the time I do want a direct mapping of the database, but there are often times when I need to add a layer of abstraction/validation/redirection on top of it.

The direct mapping of the database that it provides isn't really direct, and the impedance mismatch makes a mess of what could be a simple, easy to understand in-memory application model.

Re: (Some) ORM haters do get it

#107

Post by bkirkbri »

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'm pretty sure that this is the motivation behind http://datomic.com

Re: (Some) ORM haters do get it

#108

Post by bunderbunder »

mistermann wrote: post #21
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)."

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

The problem is, in the real world the performance divide between iterative and set-based solutions often spans much more than just one order of magnitude. For someone who's got solid experience in constructing set-based queries, the SQL solution can quite often be simpler to read and refactor as well. That's admittedly a big 'for', though. Good database folks reason about this stuff in fundamentally different ways, and there's a lot more to creating a good database person than simply teaching a programmer SQL.

In respects like that, ORM's greatest benefit is also its greatest downfall. Using an ORM means you can put people who don't have a strong grasp of databases in charge of your databases. Sadly, it also means that you've put people who don't have a strong grasp of databases in charge of your databases.

For that matter, only needing to be "fast enough" is fine if you're the only kid in the playground. That's often a safe assumption to make if you're writing app code, but less so with databases. If the database is being shared by a number of applications, or if the server is hosting multiple databases, or if you have to worry about concurrency, then being "fast enough" probably isn't enough. Because you've also got to think about all the other ways that your queries could be affecting everyone else, and making sure you aren't subjecting your server to the tragedy of the commons.

Which comes to another nice thing about having a dedicated database person. It means there's someone whose official bailiwick is the DBMS. If app A isn't experiencing any performance problems itself, but is causing performance problems for app B (say, because of some perverse locking situation), that's a bug that a DB guy is best positioned to diagnose and fix. If the application isn't too tightly coupled to the database (i.e., sprocs are in place) then he can even quietly fix it on the server side without having to hassle anyone about the application code. A team that's too ORM-reliant, on the other hand, risks failing to include anybody who's even well-equipped to recognize the problem, let alone fix it.

Post reply on HN