[Zope3-dev] Yet Another Relations (aka Reference) Engine...

[Reinoud van Leeuwen]

On Fri, Nov 11, 2005 at 04:44:47PM +0100, Jean-Marc Orliaguet wrote:
> Reinoud van Leeuwen wrote:
> 
> >On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
> >  
> >
> >>A relation is an object providing the IRelation interface. This 
> >>has got two attributes ('first', 'second' - dyadic relation) or 
> >>    
> >>
> >
> >I've done this kind of thing in relational databases. Problem with 'first' 
> >and 'second' is that it seems to imply some order. And if I try to find 
> >all relations from an object I allways have to compare my ID to either 
> >first or second.
> >
> >I solved my problem by chopping a relation into three parts: the relation 
> >itself and both endpoints. In my database this generated an extra table 
> >(and some more work when writing queries), but the solution became more 
> >generic and flexible in the end.
> >
> >(See the database diagram on 
> >http://www.drbob.org/datamodel/drbob_datamodel.htm . The two endpoints of 
> >a relation are stored in two object_link records, the relation itself in 
> >one link record.) 
> >
> >  
> >
> 
> Hi!
> 
> I think that you want 1 relation that consists of:
> - the elements in the relation (the relates)
> - the predicate
> 
> then you can chop the relations into piece when you index it, but not
> before.
> 
> a relation is by definition 1 entity, if you start storing 2 items to
> represent a single relation, you will have problems looming ahead when
> it comes to managing the different "parts" of the relation. For instance
> if you store A -> B and B -> A to represent A <-> B, you will have to
> destroy A -> B if you remove B -> A.
> 
> This is why I use real triadic relations to avoid having complicated
> constructions based on  dyadic relations that only make sense when
> they're taken together. When I destroy a triadic relation between 3
> objects, this is done in one take, not three takes.
> 
> then order in a relation is important:
> 
>     A kills B
> 
> is not the same as:
> 
>     B kills A
> 
> of course if the predicate is :
> 
>    __ is like __
> 
> it appears as though order is not important, but it is a question of
> semantics, not a question of logic. A relation engine is not supposed to
> know about semantics.

OK. In a relational database you can solve the 'one entity stored in 
different tables' with triggers. But this discussion is not about a RDBMS 
";-)

As long as the relations you propose have a direction ('kills') it makes 
sense to stored them as 'first' and 'second' somewhere. But when the 
direction is symetrical ('is like') this implementation does not feel 
right. Of course it is possible in Python to make a class around it, but 
still if a piece of code wants to find all related objects it has to 
search both the 'first' and the 'second' field.

That sounds less generic than it could be in my opinion.

-- 
__________________________________________________
"Nothing is as subjective as reality"
Reinoud van Leeuwen    reinoud.v at n.leeuwen.net
http://www.xs4all.nl/~reinoud
__________________________________________________