At 02:14 PM 11/23/2003 -0800, Dylan Reinhardt wrote:
<much snipped> Basically you have a many-to-many relationship between pieces and composers. In Zope, I find these are best modeled as objects in *peer* containers. Thus, you might have:
MusicLibrary/ Composers/ Verdi Pieces/ Aida Otello
The Verdi object would then have a "pieces" property of [Aida, Otello] and each of Verdi's operas has a "composers" property of [Verdi].
While this is a straightforward M:N approach, it is not recommended for most applications because each piece of information is recorded twice, not once. Fact: Verdi wrote Aida. This fact should be recorded only once, not twice in two different places. This is standard practice when developing SQL database applications in order to (1) reduce storage needs and (2) to avoid the type of database error that can creep in any M:N storage problem where one side is updated or corrected (Verdi did not compoe "Hair") but the other part of the database is accidentally left uncorrected ("Hair" was composed by Verdi). When the data fact is stored only once, you avoid this type of problem... it is also easier to code updates to only one table than to two or more tables. That said, I have less experience developing M:N database structures in an object-oriented database like ZODB. There could be other reasons why you might indeed want such a structure... like speed. But that's what indexes are for, so I doubt that would be the reason. My leaning is toward Dennis's suggestion... use SQL. It seems a straightforward application there. Best wishes... =Paul