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

81–90 of 108 posts

Re: (Some) ORM haters do get it

#81

Post by mistermann »

pradocchia wrote: post #73
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.

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

Agreed. If the costs were equal, I would always implement business rules in the database. I doubt many people would disagree with that. The problem is, it takes longer to write and debug. However, despite this, I think there is a certain subset of rules the belong in the database without exception - constraints and things of that nature.

Re: (Some) ORM haters do get it

#82

Post by jshen »

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?

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

This is ideological, right? What's most important is the business. Anyone that starts from the assumption that everything, EVERYTHING, must serve the end of the data, is wrong. Right?

We can make up interesting dilemas all day. How about this one. There is an optimization that facebook can make which is shown to increase monetization by 10%, but it creates soem risk of data corruption. Engineers estimate that it will corrupt 0.01% of facebook posts. Do you choose a 10% increase in monetization, or does everything have to serve the end of data integrity?

Re: (Some) ORM haters do get it

#83

Post by romaniv »

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…

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.

Re: (Some) ORM haters do get it

#84

Post by mistermann »

nbm wrote: post #69
silverbax88 wrote: post #53

Earlier quoted context omitted.

I'm not sure where you're working that there are no DBAs..not an enterprise shop. Honestly, every time I see how badly Facebook handles data and caching, I can't help but wonder why they don't use a real data store and DBAs.

I would be interested to know what you mean by "real data store", and what you believe Facebook does badly at in terms of handling data and caching and how it could be improved. (I am an engineer/developer/whatever at Facebook, and I'm always interested in hearing the perception of the company's technology from the community.)

I have two questions:

1. I've always been under the impression that for what Facebook does, a traditional RDBMS simply cannot handle the scale (like, not even close). Is this correct?

2. I'm also under the impression that due to the architecture Facebook runs on, from time to time some lesser-important data (ie: a status update or comment) can be lost (temporarily or permanently) and this is not considered unacceptable. (It seems perfectly reasonable to me for this particular use case.)

Re: (Some) ORM haters do get it

#85

Post by fusiongyro »

mistermann wrote: post #79
fusiongyro wrote: post #68

Earlier quoted context omitted.

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…

I don't disagree with you. The point of the hypothetical situation is to dislodge a naive programmer from the sense that the code is the most important artifact and the database is just storage, a servant. I agree with you and jshen, that reality is nuanced and turns on the business, the system as a whole.

Re: (Some) ORM haters do get it

#86

Post by mistermann »

wvenable wrote: post #63
mistermann wrote: post #49

Earlier quoted context omitted.

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.

The argument works both ways; in fact, I think it's worse the other direction. Most projects use the ORM and just the ORM and it's against policy to write anything in raw SQL even if it's better for X, Y, Z.

I'm sorry but I don't think you're telling the truth.

I've never encountered in real life, or during any online discussion, the all-or-nothing sentiment from advocates of ORM.

Could you link to anything online where an ORM advocate argues that you should never drop down to raw SQL?

Re: (Some) ORM haters do get it

#87

Post by dirtyaura »

debacle wrote: post #77
dirtyaura wrote: post #71

Earlier quoted context omitted.

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.

One could pose a question that if you are not doing aggregation, why have SQL/relational database at all.

I know, there are several valid reasons to use SQL databases as key-value storages: they are likely more robust than NoSQL dbs, there are API wrappers for most of languages, etc.

But for many interesting problem domains reporting and data aggregation is raison d'être for software and that's why I would like to see more solutions in the spirit of SQLAlchemy Core that make it easier to restructure complex queries as a reusable pieces of code, but do not force to you to step into the world of ORMs.

Re: (Some) ORM haters do get it

#88

Post by gouranga »

chris_wot wrote: post #62
chris_wot wrote: post #57

Earlier quoted context omitted.

Your post is of limited value. What, in particular, are the issues that you have with Hibernate?

What in particular is it about my question that caused it to be voted down? I'm actually very interested in hearing the issues that the responder is having with Hibernate. Unfortunately, because they haven't stated what it is that caused them so many problems, it's of very limited value to the discussion being had.

I voted you back up. I'm slightly concerned that the down vote was simply retaliatory against the norm which appears to be Common here.

I too would like to understand.

Re: (Some) ORM haters do get it

#89

Post by fusiongyro »

jshen wrote: post #82
fusiongyro wrote: post #68

Earlier quoted context omitted.

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?

"To us, what's most important is the data, so everything else must serve that end" This is ideological, right? What's most important is the business. Anyone that starts from the assumption that everything, EVERYTHING, must serve the end of the data, is wrong. Right? We can make up interesting dilemas all day. How about this one. There is an optimization that facebook can make which is shown to increase monetization b…

Yes, it is ideological. But you're right, at the end of the day, it's the business that matters. Developers are going to have guiding principles and it's not a bad idea to evaluate them every now and then; I hope my hypothetical at least illustrates why the alternative opinion exists. I quite like your hypothetical situation, it's the best retort, and offers a great motivating example for the rise of NoSQL, where ACID compliance simply doesn't make as much business sense as scalability with less validity.

"I don't believe in hypothetical situations" -- Kenneth the Page, 30 Rock.

Re: (Some) ORM haters do get it

#90

Post by nupark2 »

nahname wrote: post #36
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)."

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 no different than a network protocol, wherein the protocol is not a direct representation of application state, and the application does not attempt to model the network protocol using the same constructs that it uses to model its in-memory state.

Post reply on HN