[ZODB-Dev] Approaching the ZODB

[Toby Dickenson]

On Thursday 20 Jun 2002 10:28 am, Michael Casaday wrote:
> 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?                     ^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^

ZODB only loads objects when you access their state. If part of that stat=
e is=20
a reference to another persistent object then it creates a small stub, ca=
lled=20
a ghost object, of size roughly 100 bytes.

> 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.

There are no ZODB-derived reasons to do this. Just implement it in your=20
natural python style.