On Tue, 2003-11-25 at 07:23, Dennis Allison wrote:
The mapping of your music spreadsheet database to RDBMS tables is straightforward if not trivial.
Precious little is "trivial" in any significant RDBMS. Any time you're working on a system that executes dynamically-generated code, several issues loom large... maintenance surely among them.
Zope's integration with RDBMS systems like MySQL is exceptionally straightforward, clean, powerful, and flexible. You can then use Zope to handle the user interaction and presentation.
PHP is every bit as powerful and flexible but requires a far-smaller footprint. If you want to develop RDBMS-bound web apps, It's not clear what makes Zope the best tool for the job.
If you choose to do the whole thing in Zope, you'll end up having to implement in Zope a subset of the relational query mechanism you'd have in a RDBMS.
With Zope providing acquisition and arbitrary traversal, there's hardly anything left for you to do. Just make one object's id a property of another object. If you can find one from the other, you have all the relationship you'll ever need. Using my data model, let's say Aida has a "piece_composer" property of 'Verdi' and there is a Verdi object in the Composers folder, a peer to the Pieces folder. To render useful composer information in a Piece object's interface, all you need to do is something like: ----- <B>Composer</B>: <dtml-call "REQUEST.set('compsr_obj', _[piece_composer])"> <a href=Composers/<dtml-var "compsr_obj.getId()">
<dtml-var "compsr_obj.title"></a>
----- And you're done. Each piece displays its composer and links to the composer detail screen. Data management is practically transparent.
It'll probably be educational for you , the resulting product will be complex and difficult to maintain, it will take a lot of time and effort, and you'll have to worry about scalability and performance.
IMO, these are the leading reasons to choose ZODB development *instead* of RDBMS. I sell support contracts, so I'm only able to stay in business by achieving short development time & low TCO. Zope eats through a *lot* of technical resources, but it's pretty good about consuming human resources... the only kind I really care about. Having developed both ways, I'm not the least bit tempted to go back. YMMV, of course. I know mine does. :-) Dylan