[ZODB-Dev] How do you handle changes to BTree key values?

[Michel Pelletier]

On Mon, 8 Oct 2001 22:22:46 -0500
 "Patrick K. O'Brien" <pobrien@orbtech.com> wrote:

> If these examples are the equivalent of primary keys in a relational
> database, I would never use either of these values as keys. 

They are not the eqivalent.

> But I don't see the need to turn object collections
> into relational structures. Objects already have identity, right?

Yes, but you don't necessarily always have a reference to an object.  A key is a way of lookup up an object by a known value to get a reference to an object.
 
> So if all I wanted was a collection of users, why would I want to use any of
> the BTrees, which required a key?

A BTree is just a ZODB friendly mapping.  It really has nothing to do with relational design.  You would use a BTree in the same way you would use a dictionary or other kind of mapping in python, or a hash in perl: when you want to look up an object in a collection given a certain key.

> What does the key buy you in ZODB?

Nothing, the example's use of a mapping is unrelated to its use of ZODB.

> Should
> the key be a value that never changes?

Not at all, the key can be anything.

> Does the key become an attribute in
> other objects similar to a foreign key in a relational database?

No.

> Wouldn't
> you just use an object reference itself?

But do you have that reference?  Sure, if you had a reference to a particular employee, by all means use it.  But if all you have is a reference to the collection, then you need some way of getting a particular value out of that collection, and with mappings you do that with a key.

Sure, I could have made the example so that you put all of the employees into a list, and then there would be no keys, but that would require you iterating over the list every time you looked for a particular employee, an operation that may take N iterations for N employees.  A BTree (or python dictionary) makes this lookup much faster.  

For a good introduction to BTrees, see (yes, it's in perl, sorry):

http://perl.plover.com/BTree/article.html

Or for much, much more details on computability in general in this area, try the book 'Algorithmics' which is a great read:

http://www.wisdom.weizmann.ac.il/~harel/books/algs.html

> Why am I finding this so difficult
> to get my brain around? (Too many years with relational?)

Probably. ;) ZODB really just provides you with an "object universe" that is persistent over time.  This persistence of your data is realy the only thing it has in common with a relational database.  The data model is completely different, it is much more free-form in an object database.  You can store just about any type of object in this universe to satisfy you data model.  Some of these objects can be lists, dictionaries, BTrees, or any types you define yourself.  The example given just combines one common type of python object, a mapping, with a type of object you define yourself.

In a relational database, you need to use keys, tables, rows etc because the data model constrains you to that.  For certain problem domains, these contraints are acceptable, maybe even desireable.  ZODB has fewer constraints, and a "key" was used in the article example becaeuse that's just how you use mappings which are very common things in python; ZODB or no ZODB.

-Michel