Comments on: ORM Is NOT Inherently Evil

By: Davy Brion

Davy Brion — Mon, 15 Dec 2008 21:06:42 +0000

Btw, the reason i’m asking is because you seem to be throwing your MVC credentials around to prove your point, whereas i’m just wondering what on earth that has to with the ORM discussion

By: Davy Brion

Davy Brion — Mon, 15 Dec 2008 21:05:46 +0000

regardless of the whole ORM vs SQL layer debate which we obviously can’t agree on, could you please point out what exactly an MVC architecture has to do with an ORM? They are in no way related, other than the fact that many people use them together… there is nothing in MVC which implies usage of an ORM.

By: Xeno

Xeno — Mon, 15 Dec 2008 21:03:53 +0000

I understand your skepticism, after all you are a true believer and probably haven’t had to scale a 10 terabyte database yet for over 1 million daily customers. I don’t expect you to believe I have read and tried this with my team after all you believe whole heartedly that this stuff works.

But having tested this and benchmarked it with hibernate, I can tell you it is indeed slower.

You can blame it on developers all you want. You can sit here and say everyone else is wrong. You can tell me as the maintainer of an MVC framework that I am wrong as well. But it won’t stop people from saying it. And at some point, you may just do your own benchmarks against a sql layer… and you may find the same exact thing.

I guess trying to talk anymore on this would be like Jesus trying to convince the Pope that he’s an athiest.

By: Xeno

Xeno — Mon, 15 Dec 2008 20:56:58 +0000

Seriously, it’s an MVC framework. We don’t take these moves slightly. It’s a complete rethinking of the framework and ORM maes it EASY for people to handle databases. That’s a big plus.

However, there is always an engineering tradeoff; you cant make something easier to use without adding bloat. Ruby found that out when people kept saying that it doesn’t scale and CTO’s started dumping it. ORM is also problematic in the same way.

Does this mean it is not useful? No. For small and medium projects that do not expect large amounts of growth and don’t have a DBA or other development resources, this may be ideal. But for those who do have a DBA who can tweak the queries for speed and scalability and if you do plan your website for growth, you should be ditching ORM and be building an SQL layer as you will be hand coding everything anyway.

Friends of mine who work for AT&T who went with ORM for one of their apps ended up hand coding ALL their queries and I asked ’so what is the point of ORM then’ and they said ‘basically none’. They could have done this with a sql layer just as easily and actually saved ALOT of time.

By: Davy Brion

Davy Brion — Mon, 15 Dec 2008 20:55:56 +0000

sorry to tell you this, but then you really didn’t read the documentation on what kind of options were available

Could you at least go over the links i posted instead of simply stating “it used more bandwith?”

you already mentioned that you weren’t involved with all the tests, so you can’t possibly claim that it is by definition slower if you’re not even sure how the tests were implemented. Furthermore, your other statements regarding what is or isn’t possible with an ORM are incorrect as well. How much longer would you like to keep this up? You could probably invest this time more wisely in other matters… such as making sure you know what you’re talking about.

By: Xeno

Xeno — Mon, 15 Dec 2008 20:51:31 +0000

Tested with hibernate. Thats what we were using.

Thats why I stated the above.

By: Davy Brion

Davy Brion — Mon, 15 Dec 2008 20:51:10 +0000

seriously, take a look at the documentation… there are plenty of ways of fetching only the data that you need.

You can also use joins when you _need_ to, or you can avoid them when you _don’t need_ them

Please don’t make statements that are incorrect, it really doesn’t help your arguments at all

By: Davy Brion

Davy Brion — Mon, 15 Dec 2008 20:47:40 +0000

for starters, you could take a look at this:
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/querycriteria.html
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-fetching
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-multi-query
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-batch-updates

there is a lot more information available on how to properly formulate queries and how to properly use an ORM. You just have to be willing to properly investigate a technology before you dismiss it.

By: Xeno

Xeno — Mon, 15 Dec 2008 20:46:27 +0000

I mean as a classic example, if I just need to grab a login from the user table and no additional data, I have to pull the entire user object thus pulling ALL user data mapped to that user. This is bloated. Doing this for one query is nothing but for 1000 or 10000 adds up.

Doing joins are impossible unless you explicitly declare them and then what is the difference between that and an sql layer? None. To optimize, you again have to go back to hand coding sql which is the whole point to getting your database to be fast and scalable.

To which the sql layer is the best answer again.

By: Xeno

Xeno — Mon, 15 Dec 2008 20:42:37 +0000

Then provide an example because all the examples and data I have read are similar to that guys example where the mapping is very static and you are expected to recycle objects rather than building the query to fit the job.