Roché Compaan wrote:
* Shane Hathaway <shane@zope.com> [2003-04-30 16:55]:
Do you agree with these requirements and minimal use cases? Is there anything I need to clarify?
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 now I can think of two possible models: - Store and index relationship objects. This is perhaps the most obvious way to do it. - Use relations (database tables) and infer relationships rather than store them. This could allow us to take advantage of relational theory. The advantage of storing relationship objects directly is that it's obvious. When you want to relate object A to object B, you just create a Relationship object that links A and B and store it. You can store extra metadata by creating your own relationship classes. Relationship objects need only implement a minimal interface. The disadvantage of storing relationship objects is that every relationship is stored as a separate object. But in a complex application, aren't there potentially far too many relationships to enumerate? How would we manage this? And would it be possible to infer relationships? The advantage of using relations is that it gives us the benefits of relational theory. Relational theory provides a clear way to store and query relationships efficiently. It lets you infer relationships based on explicit relationships. The disadvantage of using relations is that relationships have to be decomposed for storage. You can't just add an attribute to a Relationship object and expect it to be stored; you also have to arrange for the corresponding relation to store another column. (Although you might automate the process by telling a relation to keep its schema in sync with a particular class.) Either solution provides a way to store and retrieve simple relationships. The difference is in the way they can expand. I like to imagine that the relational model was developed for the purpose of scaling the entity relationship model, but that's a wild guess. I suppose mxmRelations stores relationship objects directly. A ZCatalog instance, on the other hand, is much like a relation, although it doesn't implement all the same operations and provides some extra operations. Shane