On Sun, 2003-11-23 at 17:39, Paul Howell wrote:
At 02:14 PM 11/23/2003 -0800, Dylan Reinhardt wrote:
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.
An excellent point. If that's important to you, you could record it in only one place and the object hierarchy is still a good way to model this data. But a little redundancy *can* be a good thing in this domain, so long as it's managed well. In web apps, you often drill into data in arbitrary ways. Why should it be cheap to know who wrote Aida but expensive to know what else Verdi wrote? What's critical here is having *one* way of creating & changing the data. So, for example, you can create and edit composer objects independently, but can only assign composers to pieces in the piece management screens. That said, it may be best to think of each piece object as a large mapping for composer, artist, etc. Objects. If that streamlines development substantially, the extra cycles are well spent.
Fact: Verdi wrote Aida. This fact should be recorded only once, not twice in two different places.
More generally, you should have exactly one *process* for creating and maintaining each bit of data. There are any number of reasons one might choose to allow some redundancy in how data is accessed.
This is standard practice when developing SQL database applications
Understood. Zope at its best works almost nothing like an RDBMS.
My leaning is toward Dennis's suggestion... use SQL. It seems a straightforward application there. Best wishes...
You could certainly do that. If an RDBMS is the tool you're most familiar and comfortable with, that's probably the best solution for you. But this is *exactly* the area, IMO, where ZODB shows more power, intuition, and flexibility than SQL. It's not hard to understand why LAMP became the dominant method of creating web apps: it leveraged existing skills and assets. But Zope reflects much of what's been learned about web apps *after* LAMP caught on. You *can* use Zope as a high-octane PHP, but Zope is also capable of managing data in new and more interesting ways. If you're more comfortable with RDBMS/LAMP development, use that. But know that there is also value to breaking that mold. FWIW, Dylan