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

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:akUwa.11$MU1.58_at_news.oracle.com...
>
> "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.

That's a very good point. Clustering will further reduce the single random IO to zero. Received on Fri May 16 2003 - 00:32:56 CEST