There's a problem that's inherent to any client/server architecture: what work should get done on the client, and what should get done on the server? The author presents this as an ORM issue, but it has nothing specifically to do with ORMs; you'd have the same problem using an OODB server.
(Some) ORM haters do get it
91–100 of 108 posts
Re: (Some) ORM haters do get it
#92Earlier quoted context omitted.
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 unacceptab…
With respect to #1, I believe they use a heavily sharded MySQL cluster for at least part of their work. But I also believe you're right about #2.
Re: (Some) ORM haters do get it
#93Earlier 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…
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.
Re: (Some) ORM haters do get it
#94Earlier 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…
IME you can always still write direct SQL when appropriate.
Re: (Some) ORM haters do get it
#95He's wrong. SQL is great for what it does, but I use ORMs for reasons other than writing queries in a different way. I inherited an utter mess of a schema that wasn't even remotely close to 1NF. Imagine fields containing comma-joined sets of values, and with column names not even remotely related to what they actually held. For legacy and business purposes, updating the schema was a non-starter. So I used SQLAlchemy…
This is an interesting use and I like the idea, but I don't think it makes him wrong. You don't actually need an ORM to do this. The same logic could be applied to data sets retrieved through regular queries. Or you could create views/stored procedures with the same logic.
Re: (Some) ORM haters do get it
#96Earlier quoted context omitted.
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?
The attitude is prevalent in the design of many ORMs. I'm both a huge advocate of ORMs and of SQL. A good ORM provides a simple and direct mapping from storage to the object model. But most ORMs go beyond that and try to cover all the query and performance possibilities available from SQL. Some ORMs have their own text-based query language!
I've met developers who can happily (and effectively) work with an ORM but hardly even know SQL! They certainly don't know SQL well enough to use it in the situations were it would be most effective.
I'm starting to feel like really effective set-based understanding of SQL is becoming sort of a lost art.
Re: (Some) ORM haters do get it
#97This 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?
Row-By-Agonizing-Row, or iterating over a list of rows and operating on each individually with a new query.
Your average Java programmer is used to iterating over collections in a while loop, where 30,000 in-memory objects can be quickly modified. It's tempting for said programmer to do the same to ORM-backed objects and issue 30,000 sql update statements across the wire.
Re: (Some) ORM haters do get it
#98I 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,…
Is it Man or Woman important for successful marriage? Your comment sounds similar to this :) I do not hate either. ORM or not, developers dealing with db data needs to understand how it works. If they do not, they may still come up with working application but when performance issues come up, they become deer in headlights.The same argument applies to ORM or any other technology. Long time Hibernate user here.For me, Martin Fowler's article hits the nail.
Re: (Some) ORM haters do get it
#99Earlier quoted context omitted.
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 unacceptab…
Perhaps it is best for the database team to talk about that themselves - wouldn't want to put words in their mouths. They gave a Tech Talk in December last year, which you can see at http://livestre.am/1aeeW
Re: (Some) ORM haters do get it
#100Earlier 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,…
This is a fantastic comment, you need to post this as a blog post, and then submit to HN. This way I and many others will never have to rehash this again, just point back to it.