On Oct 8, 2005, at 7:26 PM, Patrick K. O'Brien wrote:


>> BTW, is "OODBs" the correct plural form?

That is the way I would write it.
>
>> A user can and should create "indices" - mappings from keys to
>> objects (or
>> OIDs). These indices help to fetch objects; they also are there to be
>> iterated over, so the user does not need to fetch and test an
>> every object
>> in the loop (which can be quite memory- and time-consuming) - it
>> is enough
>> to iterate over an index and fetch only those objects that the
>> user really
>> needs; the index iteration is usually optimized time- and memory-
>> wise.

Are you talking about iterating over the keys of an index, and loading
some subset of the values based on information that is encoded in
the keys?  That possibility does not seem to me to be a fundamental
reason for the indices (perhaps because we never do that in our
applications).

> IMNSHO the database should do these things automatically, based on a
> declarative syntax of the desired keys and indexes.  That's what
> Schevo
> does.  Here is a snippet from a Schevo schema:

I'm glad for that to be a possibility, but "should" is not the right
word.

>> Serialized objects are the only "things" in a database. Indices
>> are also
>> such objects.

Right.

>> special iterable objects (sequences or enumerators), usually
>> implemented as
>> (binary) trees for efficiency.

In Durus and ZODB, the trees are usually BTrees whose nodes have degree
 >2, so they are not really binary trees.

> Why shouldn't the database do more, like enforce referential
> integrity,
> automatically maintain bi-directional links, provide cascading (or
> restricted, or unassigning) deletes, intelligent fields, enough
> metadata
> to support a dynamically constructed UI, etc?  Schevo does.

I think it is great to have these additional features as a
possibility for
applications that need them.   When I think about the applications
we run here, though, I can't see any of these as needed.

>> Creating and deleting objects (including indices), and iterating over
>> indices are main (if not the only) tasks related to OODBs that a user
>> performs. All other manipulations with objects are outside the
>> scope of
>> OODBs, though OODBs that support automatic persistence take notes
>> when
>> objects are modified and store (serialize) new and modified
>> objects at the
>> end of a transaction.

yes.
>
> Automatic persistence is the wrong approach and is a waste of time and
> effort.  Transactions as explicit objects is the right approach.  You
> can guess which approach Schevo supports.  ;-)

Please explain this.

>
>
>> When developing programs a user is mainly confronted with the
>> following 4
>> problems related to OODBs:
>>
>> * devise an object scheme - classes, attributes, object hierarchies;
>> * name the objects (create indices);
>> * upgrade (change) the object scheme;
>> * remember to update all indices whenever an object is created,
>> modified or
>>   deleted.
>>
>
> The stuff in your list is all the good stuff.  Leaving all that to the
> user is why traditional object databases haven't had much of an impact
> on the world of database technology, imnsho.

Devising and maintaining the scheme is no more difficult than it is in
other contexts.
Naming objects and maintaining mappings does require some energy
in the OODB context, but, honestly, it seems tiny in comparison to the
energy required to understand and use a traditional database.

Indices are important in our applications, but they are not as dominant
as you might imagine.  References are really the dominant structural
feature.  We often use an index to find an object, but the rest of
the database operations involved in servicing a request are usually
just a matter of following references to get information needed to
make the response.   When we do searches, we're just iterating over
some set of objects and picking some:  we follow the references
of those instances as needed for the response.


> BTW, we are very close to a formal release of Schevo, which has
> been in
> stealth mode for about 4 years.  In the mean time, feel free to get
> the
> code from our Subversion repository and ask any questions if you want.
> BTW, yte version that we are about to release uses Durus
> exclusively as
> its storage engine and it is working so well that we may not have a
> need
> to support ZODB, Pypersyst, or any other storage mechanism.

All good news.