Hi,

I'm interested in OODBMS design and have a few basic questions:

1) What kind of indexing technology is preferred today? Hashing,
B+-trees? Other?

2) In a OODBMS system, strings can have variable lengts. How are these
strings stored since, obvisouly, fixed-sized records wont do?

3) Are object graphs stored close together (for fast loading of
graphs) or are objects of the same type stored closed (for fast
loading of lists of the same object type)

4) How are secondary key searches implemented (data structures, etc)

5) Anyone know of any good books on this topic?

Thanks for any info!

-han

"hantheman" <hantheman12 (AT) hotmail (DOT) com> wrote

It depends on the data you want to index, doesn't it? One great thing about
OODBMS is that if you have access to object IDs, the choices for indexing
are practically limitless, not only to the database provider, but also to
the application developer. Even spatial indexes have been developed for
Objectivity without having to change the kernel.

This probably varies from vendor to vendor. Objectivity uses separate pages
for varying length data with an internal pointer (OID) from the object to
the page(s).

Again, this varies from vendor to vendor, but with Objectivity, you can
specify how you want to cluster data. When you create an object, you can
cluster it with another object and Objectivity will try to put the objects
on the same page or at least one that's close. This allows the application
developer to make the decision whether to group parents together or parents
with their children or whatever. Of course, the application developer can
also expose the choices through their own interface and offer the choice to
an administrator or end-user.

There are lots of ways. For example, you can create a hash map of object
IDs using the secondary key and object IDs as the value. That's obviously
very fast for lookup, but will add some overhead.

Most OODBMS products also offer some kind of query language that's similar
to SQL. In Objectivity you can scan databases and containers for objects of
a given type with predicates using regular expressions (e.g. 'length < 5 &&
title ~= "*database*"'). You can also do this within associations (e.g.
iterate over all books pointed to by the "Paul" object where 'length > 5 and
title ~= "*database*"').

How these scans are actually implemented underneath the covers depends on
whether the secondary key is indexed, the scope of the search, etc.

Are you looking for how to build an OODBMS or how to use one? There aren't
many OODBMS books, but there are a few. There are also lots of white papers
provided by vendors. Of course, these aren't purely objective (books aren't
either), but one can learn a lot from them.

I've found that for using an OODBMS, the best approach is learning both good
OO programming techniques and fundamental database concepts (concurrency,
transactions, etc.). Books on both of these are readily available. For
example, if you know how to use a hash map in C++ or Java, you'll be able to
use them in the same way most pure OODBMS implementations.

The oodbms-specific implementations are, of course, best described in the
manuals.

Paul DeWolf
Systems Engineer
Objectivity