ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button
  Lightweight R/O Mapping
Subject:   More on the things the author of this article got horribly wrong
Date:   2005-12-08 09:00:54
From:   SeanReilly
(aka: Welcome to programming)

In my previous post, I commented on the author's skill and experience with java generics (or horrible lack thereof). This time, the subject is databases, and how the techniques mentioned in this article are an excellent example of how not to access them correctly.

From the original:

Et voila, there you have all of the Jedi with a collection of their respective fighters. Note that we have not coded the reading of the Fighter collection into the Jedi class. This would mean tight coupling between the Jedi and the Fighter.

Wow. Sir, if any of your databases are on fire, may I humbly suggest the above code as a possible culprit.

With the exception of a few highly specific cases which are well beyond the scope of an article like this, a relational database process and a java application server are never in the same process. In fact they are commonly not even on the same physical server. This means that the round trip from the app server to the database has cost, often measureable in milliseconds or more.

Consider a case where there are 10000 jedi, each with 0 or more ships. Querying this information in a join would incur the cost of 1 roundtrip. The method described above would incur the cost of 10001 round trips. If you've ever heard some of your more knowledgable colleagues mention the n + 1 loading problem, this is what they were talking about.

In addition to the phenomenal overhead incurred in app server/database traffic, this approach is also more expensive at a pure database level. The join can be processed as two ordered table scans, plus a nested loops join operation. In constrast, the n + 1 loading approach will incur 1 table scan, plus 10000 index seeks.

For someone whose stated goal is minimizing poor database behavior, this is coming up a bit short.

As the author of this article is also the author of the library in question, my concerns about the quality of the Amber framework are grave indeed. It's too bad really, because I agree that slaving the object behavior to the relational behavior is a promising approach to minimizing o/r impedence.

In the mean time, where's BileBoy when you need him?