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.