Re: Object databases beat joins (was: Re: ODMG Website?)

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:ba0vh0$7as$03$1_at_news.t-online.com...
> andrewst wrote:
> A very simple example:
> Imagine you have a database with 2 billion of hydrogen atoms, joined
> together to one billion of hydrogen molecules. If you have one atom
> and want to find the corresponding one, your index solution will have
> to walk the complete tree consisting of 2 billion of index entries.
> They may not fit into RAM, I am afraid. Alright then, if you have
> a perfectly balanced tree on your hard disk, you will need at least
> 31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
> An object database typically references objects directly. Access time
> is constant:
> Walk one pointer!
> ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> You can get away with one singel read operation.
> That's the best performance you can get.
>
> In huge databases, index construction and maintenance can also become
> a performance problem.

Wrong arithmetics. A typical B-tree having 1G nodes will be 4 levels deep. 3 levels would typically be cached. Therefore, we have 1 random IO, the same as in the OODB case where the foreigh key reference is expressed explicitly by a pointer. Received on Fri May 16 2003 - 00:08:53 CEST