Hello!
A simple example would be: customer-class in one folder, purchaseorder-class in another, productitem-class in a third; select all purchase orders for customerA, displaying each individual productitem ordered.
Why would you have those three things in different folders? Why not, for example have:
[... skipped ...]
Seems the object orientation of python makes something like this the natural organization, as opposed to the table orientation of a so-called RDB....
Then in Zope, you'd naturally take steps to Catalog these things as they were created, facilitating high speed searches and report generation.
Marc is right that most of the problems CAN be handled in an object-oriented way and using the catalog for indexing the rest. In fact, whenever you know in advance which queries you'll need, it should be no problem to model the object and indexing structure accordingly. But as soon as your customer asks for a new, cross-object query or just wants to be able to "dig in his data", SQL-based data storage is way more flexible, in some cases even the only viable solution. This is why the SmartObjects project (http://demo.iuveno-net.de/iuveno/Products/SmartObjects) exists. It aims at merging the two: Data stored in RDBMS tables should be usable as objects within Zope, but at the same time SQL queries should be possible. That's actually a bit of a simplification, as SmartObjects are supposed to also handle objects stored in LDAP or the filesystem, and even "composite" objects. But basically the issue you have would be tackled. If you are interested, just read the mailing list archives of SmartObjects and join the list ;-) Joachim