hierarchical nested data structure in db4o (or any other oodb)

Question

Really my question is, if I were to use a nested data structure in oodb would I be placing instance of classes within other instances in the db, or is there some sort of relational mapping that would be required.

I've been interested in OODB (Object Oriented Databases) for a year or so now. I'm a web/application developer in essence and for a while now have been noticing the severe limitations both in terms of complexity and performance of representing complex hierarchical structures such as a website hierarchy in relational models such as MS T-SQL and MySQL.

To present a quick java (pseudo-code) example:-

CLASS/DB TYPE:

public class PageObject{

    public String title = "";
    public String shortname = "";
    public boolean published = false;
    public PageObject[] pages = null;

    public PageObject() {}

}

So if we started with this class, which would be capable of holding other instances of the same class in the pages array (or vector, or collection or whatever) we could eventually end up with the possiblity of having a site layout as such:-

• Home
  • First Home Child
    • 1
    • 2
    • 3
  • Second Home Child
  • Third Home Child

Looking at this we can see that the Home item would have 3 items stored in it's pages collection, with the First Home Child item within this collection having a further 3 items in its own pages collection.

If we were to then store this structure in DB4O (or any other OODB) would this present problems in terms of performance, in that any calls for top level objects such as the homepage would also return ALL items beneath them, assuming the database grows significantly?

This question might appear quite subjective, for which I apologise in advance, but I just can't seem to wrench my head out of the relational model so am having real problems even trying to plan out any kind of data model, before I progress into further work in code.

Any clarity anyone can shed on this would be absolutely appreciated at this stage! Cheers in advance for any thoughts!

Answer 1

This is where OODBs are precisely a fit, when you're dealing with complex object hierarchies where tables and joins feel overkill. db4o (and other oodbs such as Versan't VOD) do not need to use joins (as in an rdbms) and deal with the relationship between objects transparently (as defined in your object model). In essence your object model ends up being your data model or schema. These oodbms systems usually perform better than rdbms when dealing with nested structures and can even handle cyclic references.

In order to avoid loading/storing more objects than expected oodbms can work with arbitrary levels of object activation (or update) depth (for example in your example you can tell the db to only retrieve/update first level home childs). Alternatively you can configure them to wok in transparent persistence mode (as Sam suggests) where the db only retrieves or updates what you access on demand (ie. as you navigate your object tree).

More info (db4o): http://developer.db4o.com/Documentation/Reference/db4o-8.0/java/reference/Content/basics/activation.htm

HTH

Best!

German

Answer 2

If your hierarchy is truly a tree, wouldn't it be better to model this using a parent relationship (sorry, I can't bring myself to use a class named PageObject):

class Page {
  Page parent = null
}

? You could then find the roots by searching for all Page's that have a null Parent.

In general, you should also learn about transparent activation.

Another way that is 'semi-relational' is to define Page objects with no containment information and containment relationship objects:

class Page

class Contains {
   Page container
   Page contained
}

Here, pulling a Contains object out of the database at worst pulls out two Pages. You need to manage Page deletions carefully though.

PS: pardon my abbreviated Java, I'm getting too used to Scala.