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!

score 4 · Accepted Answer · answered May 27 '11 at 14:02

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

Thanks for such a concise answer German. If I can prod a little further too though. With a hierarchical structure such as the one described, would there be any scope to reach into the db at an arbitrary level at any point, or would all operations have to be methods acting on the root of the tree? What I mean is, would an application interface be able to get say Page "3" immediately, or would this require some iteration, from "Home" through "First Home Child" and finally to "3" to retrieve this object within the hierarchy. Cheers again! — BizNuge, May 28 '11 at 09:39
Remember that these system are not only navigational but can also access arbitrary objects via different querying systems (in db4o SODA, native queries, etc. In others ODBQL, etc). They also support indexes to make queries fast. They are even optimized so when you're trying to reach one member of a collection you don't have to traverse all the collection. So you don't necessarily have to reach persistent objects through navigation from a top level. — German, May 30 '11 at 12:08

Sam Stainsby · Answer 2 · 2011-05-26T12:00:10.090

0

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.

edited May 26 '11 at 12:00

answered May 26 '11 at 10:56

Sam Stainsby

1,588
1
10
19

To be honest Sam, I'm really quite new to all this, so am postulating with very little real information behind me. Is what you're saying this...? Rather than actually store these Page instances (Note the Object omission there) nested within each other, they'd be better in a flat structure with some referential tie between their hierarchical relationship? I'll have a look at transparent activation now. Quite difficult to even get started in this it seems... Cheers! – BizNuge May 26 '11 at 11:44
The are various ways to do it. I just suggested two. – Sam Stainsby May 26 '11 at 12:00

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

2 Answers2