[ZODB-Dev] Approaching the ZODB

[Michael Casaday]

I'm just getting to know the ZODB.  I'm tempted to take a really
hierarchical approach to the database for my app, where objects own
objects which own lots of other objects etc etc.  This seems like a
natural approach to take with an object database.  However, it
occurred to me that such an approach could be inefficient, depending
on how the ZODB works.  I'm wondering if anyone here can assuage my
misgivings.

Say I have persistent classes Author, Book, and Page.  Author's have a
relatively short list of Books.  Books have a relatively large number
of Pages, kept in an IOBTree.  Pages are fairly small memory-wise by
themselves, but if you added up all the Pages in a typical Book you
would have a collection of objects large enough to make you think
twice about loading them all up in memory.  Ideally you would only
want a few Pages in memory at any given time.

Let's say my databases's root is a dictionary of Authors.  If I pull
an Author from the database, and that author has a few Books, and each
of those books have a whole bunch of Pages, does the ZODB pull the
whole mess into memory?                     ^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^

Would it be wiser to take a more relational database-esque approach,
and use IOBtrees to index all of the Pages, Books, and Authors by some
unique ID number?  In this approach there might be IOBtrees called
'books', 'authors', and 'pages'.  An Author, instead of having a list
of Book objects (like in the first example), would instead have a list
of integers corresponding to the keys of its Books in the 'books'
IOBtree.

Thanks!

_______________
mike