Brent Simmons has a very good piece about switching away from using Core Data to using SQLite directly in his iPhone app. Substituting “any common ORM” for “Core Data” (which, after all, is all Core Data is) and “any SQL database” for SQLite, he encounters the most common problems that plague those trying to develop scalable solutions on top of ORMs.
✦ ✦ ✦
Comments
Anonymous Coward · 28 February 2010
Right. If you don't know what else to blame, and you are a "database guy", you blame ORMs. Even if they differ a lot, and those targeting relational databases always provide a way to drop down to just SQL. Right. Got it.Anonymous Coward · 28 February 2010
And, of course, you do not say that SQLite is so painfully slow Apple's Mail wasn't really useful with more than 1000 emails at the same time on Leopard. And they do use SQLite directly, it seems. And neither you, nor Brent say that usually only reads need to be switched, and validation plus writes are actually so much more painful and hard to test with "straight SQL" or SQL functions, than using ORMs for that part is simply the only reasonable thing to do. Of course. More two sentence posts that blame ORMs unconditionally. Go for it, database people!Anonymous Coward · 28 February 2010
"In Core Data, I had to loop through the list, change the status for each individual item. The list could be up to 10,000 items long. Not a good idea." — not all ORMs are that bad. Many many good ORMs (ActiveRecord, Hibernate, you name it) has a way to do that exactly in one query, built-in. Substitute "The Build" with "Yet another blog post writer who makes 'one size fits all' claims without explaining any details" and you discover the most common problems that plague those trying to write blog posts while being biased, unfair and (I bet) not even being closely familiar with the subject.Xof · 28 February 2010
Sigh. Setting aside that I did not "blame ORMs unconditionally" for anything, the reality is that naive use of ORMs can result in scaling issues. Whether or not SQLite is fast, slow, peppermint-flavored or useful as a tree-trimmer is irrelevant to that point; the ORM can't run any faster than the underlying database. It is worthy of note that at the point the main feature being touted of an ORM is that you can bypass it and drop down to raw SQL, a reasonable person might wonder why one should use the ORM in the first place. It's like saying the great feature of a file system is you can bypass it for the block device. I have no inherent problem with ORMs; I use them all the time. But they can result in some really, really bad usage patterns by people who do not understand how the underlying database works.Xof · 28 February 2010
My goodness, such venom. You might want to get out more. Of course there are good and bad ORMs, and there are good and bad usage patterns of that ORM. I'm amused at the hostility towards "database people," given that ORMs would be kind of silly without the underlying database. I wonder if there was a time people ranted about those "file system people"?Anonymous Coward · 1 March 2010
There is no hostility towards "database people". It is just hilarious how little attention people pay in their writings to details that really matter. "Oh, here is one more incompetent developer who struggles from problem A with technology B. Use of B (ORMs, SQL databases, language N, framework M) should be questioned, yeah!". You can have 300N + 1 queries issue without using any ORM. Just do a few nested loops and UPDATE call to each individual entry for no good reason. How that is a problem with ORMs? That's a problem with incompetent developers. So call it that.jdbo · 2 March 2010
The original post does not characterize the Brent Simons as "one more incompetent developer", in fact it is complementary to him ("Brent Simons has a very good piece"). The AC is reading negativity into the original post that is simply not there.Xof · 2 March 2010
I believe it is actually the AC who is characterizing Brent Simmons as an incompetent developer. Setting aside the inappropriate personal attack, Simmons' post can be summarized as, "I was having bad performance problems with Core Data. Through diligent analysis, I came up with this solution," which was dropping down to raw SQL... a feature that the AC implicitly endorses. So, I'm really not sure what kind of incompetence the AC is complaining about. And the argument that "this other ORM over here" doesn't have a particular issue assumes that you have the luxury of switching to a different ORM... and, of course, that ORM over there might have its own set of interesting characteristics. My point was never that ORMs are evil, just that they can create some serious scalability issues if they are used naively (and, really, a constant selling point of ORMs is that you "don't have to know SQL" and can use them just as if they were in-memory objects, so naive use is actually encouraged as part of the glossy brochure). The danger is that this works fine on a system with 10 concurrent users, and then melts down with 10,000, but at that point, your architecture is stuck. And if the point is, "Well, a superior developer will always use tools in the best possible way and never get into these situations," that's a great goal, but here in the real world of mere mortals, a little advance guidance can be very helpful. "ORMs never fail developers, developers fail ORMs!" is an entertaining slogan, but I don't think it's very accurate.