[Zope] [OT] OO/RDB

Aurélien Campéas aurelien.aa@wanadoo.fr
29 Jun 2003 19:33:52 +0200


First, thanks to both of you for your answers.

Le sam 28/06/2003 à 19:19, Dieter Maurer a écrit :
>  > > The ZODB supports an openly extensible
>  > > set of data types. 
>  > 
>  > What is more extensible that the combination of primitives types +
>  > relations + inclusion constraints ? 
> 
> A data type is data together with operations on this data.
> A RDB lets you define arbitrary complex relations on primitive types but only
> very restricted application specific operations.

But this restriction is because of the way most RDBMS are implemented,
isnt it ? There's nothing in the relational model that prevent you to
bundle specific complex operations with a complex set of relations (I
believe : as in "in C, you can do OO-like disciplined programming, like
in the Glib or the Linux kernel"). 

> Set and predicate theory does not restrict relations to be over
> primitive types only...

That's it !

> Whenever you need relations over complex objects you are forced into
> unnatural auxiliary tables.

Unnatural ??? 

hmm, using something braindead like SQL and pl/sql to programm an RDBMS
is off course not only unnatural but totally perverse, yes.
Implementations sucks.

But I've seen other things, like Datalog, that help me think RDBMS are
so bad only because so badly done.

>  > You can map any "OO model" into the relational model. Not the other way
>  > around.
> 
> The relational model *IS* an OO model with a very restricted set
> of (specialized) object types.

That's kind of strange. I thought about the OO model in terms of a
specific (sub)set of relations types (like inheritance, composition,
ownership, etc.)...

>  > > This might be considered "less straightforward
>  > > to understand". It definitely is not a flaw.
>  > 
>  > The flaw lies in this fact : ODBMS are really hierarchical DBMSes, like
>  > the ones of the 60's and 70's that the relational model was supposed to
>  > help throw out of the window.
> 
> The ZODB is not hierarchically (although what you see on the surface
> might look this way). Especially the object types used to build
> efficient indexes (BTrees) are not hierarchical at all (despite their name).

Ok, I know peanuts about the ZOBD - but the fact that it relies on the
python pickler to stream in/out objects. 
The only problem I am aware of with python objects is when you build
circular/cyclic structure with them : they won't be reclaimed by the GC
whenever a cycle ceases to be referenced by some outer/parent object. So
you have to implement explicit destruction (inner dereferencing) of such
a structure.
Thus the need for a rooted tree, at least an acyclic structure for what
lies in the ZOBD (as I understood it).
hmmm, I'll dig into this soon.

BTW, what do you mean when you say "BTrees are not hierarchical at all"
? The fact that they're seen as a flat ordered collection at the user
level ? Or something else ?

>  > That's not to say ZOBD isn't neat and usefull, but please. I just hate
>  > when some knowledgeable person spreads FUD on those topics.
> 
> They see the world differently from you...

I've been a bit crude, sorry.
Thanks for your input.

Aurélien.