[Zope-dev] RFC: RelationAware class for relations betweenobjects

[Shane Hathaway]

Roch=E9 Compaan wrote:
> * Shane Hathaway <shane@zope.com> [2003-04-30 16:55]:
>=20
>>Do you agree with these requirements and minimal use cases?  Is there=20
>>anything I need to clarify?
>=20
>=20
> This sounds good. Now what is the next step? I'd like to help build on
> the API or aspects of it like making it work in Zope 2 for instance. I
> like the idea of having RelationShips as a separate branch in the ZODB
> that you posted earlier.

Well, I think we should look at the way relationships get stored.  Right=20
now I can think of two possible models:

- Store and index relationship objects.  This is perhaps the most=20
obvious way to do it.

- Use relations (database tables) and infer relationships rather than=20
store them.  This could allow us to take advantage of relational theory.

The advantage of storing relationship objects directly is that it's=20
obvious.  When you want to relate object A to object B, you just create=20
a Relationship object that links A and B and store it.  You can store=20
extra metadata by creating your own relationship classes.  Relationship=20
objects need only implement a minimal interface.

The disadvantage of storing relationship objects is that every=20
relationship is stored as a separate object.  But in a complex=20
application, aren't there potentially far too many relationships to=20
enumerate?  How would we manage this?  And would it be possible to infer=20
relationships?

The advantage of using relations is that it gives us the benefits of=20
relational theory.  Relational theory provides a clear way to store and=20
query relationships efficiently.  It lets you infer relationships based=20
on explicit relationships.

The disadvantage of using relations is that relationships have to be=20
decomposed for storage.  You can't just add an attribute to a=20
Relationship object and expect it to be stored; you also have to arrange=20
for the corresponding relation to store another column.  (Although you=20
might automate the process by telling a relation to keep its schema in=20
sync with a particular class.)

Either solution provides a way to store and retrieve simple=20
relationships.  The difference is in the way they can expand.  I like to=20
imagine that the relational model was developed for the purpose of=20
scaling the entity relationship model, but that's a wild guess.

I suppose mxmRelations stores relationship objects directly.  A ZCatalog=20
instance, on the other hand, is much like a relation, although it=20
doesn't implement all the same operations and provides some extra=20
operations.

Shane