> Also, from my personal experience, when I do the O/R mapping, I
> artificially cut the object navigation paths to prevent O/R from
> loading the whole database into JVM (lazy loading is many cases
> does not work, since we need to send the object tree to another
> layer, at that time database transaction is already gone). So, in
> reality, I define the data clusters, which will be loaded at once
> from the database and kept in cache for a while.

I understand and accept that this is current best practice and that
good engineers build applications this way. But to me it is a work-
around for failing rdbms technology, not unlike MySQL's arguments six
years ago that a rdbms did not need transactions, ref integrity,
stored procedures, etc., as all of that could be done in the
application.

> And funny enough, the best performance optimization in this case is
> to fetch all data, if possible, at once - as result of one select
> with many master-detail joins instead of select-per-table approach.
> O/R mapper then reconstructs the object tree in memory. So,
> strictly speaking, I use a single "virtual" table in 1st normal
> form.

I understand this to mean that the rdbms is better at doing joins
than the application's O/R mapper. Not surprising as doing
efficient "search & join" takes up more sloc than "ACID" in the
average rdbms.

There is a relation to partioning. Current technology is good at
doing efficient single node joins, but poor at doing cross-node
joins. Many scalability engineers advocate denormalising data to deal
with it. This, too, sounds like a work-around.

Paul