Re: Re: relationships between objects

> >- a relation object, like classtaking, can have properties of it's own,
> >  like "day-of-the-week". It's not just there to describe a relation
> >  between student and class.
> >  The fundamental strength of an RDB here is that everything is a
> >  relation/tuple/table !
> 
> Hmm... that can be done if you save relations as objects (with configurable
> metadata) and gives the user the posibility to relate *normal* objects with a
> relation-object. 

True, IOW: take the relational approach. The conventional OO approach would be to
store a list of pointers in each 'class' object instance (to the students) and a list 
of pointers in each student object instance (to the 'classes'), but then if you discover 
later that the relation between 'students' and 'classes' has properties of its own, you 
have a problem.

> >- scalability.   
> 
> ??? example?

If relations between objects are stored as lists within objects the limitation is the same 
as with a normal folder object in Zope or as in the MxMRelations product (couple of thousand max), 
so a Btree+ implementation would solve this problem.

> >So AFAICS, the best solution for the above in ZODB is to take the
> >relational approach and create an object 'classtaking' with properties 
> >student_UID, class_UID, foo_property1, foo_property2, etc. This allows 
> >for a unified way of finding "all students in a class" and also "all classes 
> >a student takes".
> 
> The relation between classtaking and student / class should not be saved
> at the object itself - you preserve flexibility when you save that relation=
> as a special relation-object and adding there some metadata, or even linking
> that relation-object with a metadata object. That makes it possible to have=
> m:n relations.

:) I think we're indeed saying the same thing. the problem with Archetype relations is 
that those relations are not objects and therefore not scalable neither. 

> Look at http://plone.org/development/current/projects/ticle_folder/proposal
> There we explain that approach.

I like the Linkmanager (+ constraint manager) approach, but when you think it through
only a small nr of "normal" objects (with just some metadata) would be there  and the vast
majority would be relation objects, so the nr of what-you-call 'Triples' will be huge right?
(not that there's something wrong with that ;)



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf