Hi Max, this is a VERY interesting thread to me now, very timely. I'm just starting to work on a zope product to list software, searchable by keyword and browsable by categories (see e.g. freshmeat.net); with user reviews and comments for each item (see e.g. amazon.com.) There are many items of software that might realistically belong in several distinct categories, and furthermore I want the page for each item to have links to browse all the categories that the item belongs to. A very rough and ugly mockup is at http://www.slinkp.com/linux/soundapp_site_roughs/app_entry.html Obviously that site has a specific audience in mind, but I'd like my product to be generally useful too. So you can see why your message is interesting to me... I was just about to post some questions to zope list re. ZODB vs. SQL for a site that needs this kind of flexible relationships *and* text searching. Further suggestions would be most welcome. Now some specific comments / questions... On Fri, Apr 05, 2002 at 09:56:28PM +0200, Max M wrote: So the only logical approach is to put all objects that has many to many
relations in it's own folder like::
students/ Johnny Mary Adam Eve Math students/Johnny students/Mary Science students/Adam students/Eve History students/Adam students/Eve students/Johnny students/Mary
Yes, I thought of doing something like this... But in this approach, I was unclear on how the relationships are implemented Perhaps in your example History is just an object with a "students" property that is simply a list of the ids of Student objects from the Students folder?
Another problem with the approach that you suggest is that for every distinct content type (product/metatype etc.) that you want to add, you have to ad logic and interface controlling the properties linking objects to each other.
This means that the amount of code you must write to support relations between object types in your site, grows squared with the number of different object types you want to relate.
And still it is a pain to do many to many relations. So the next logical step here would be to put the classes in their own folder too, and then have a product that only handles many to many relations::
students/ Johnny Mary Adam Eve classes/ Math Science History Relations/ classes/Math students/Johnny students/Mary classes/Science students/Adam students/Eve classes/History students/Adam students/Eve students/Johnny students/Mary
Oh, I see. This is even better!
And then you would have another structure creating the view of the site, which could be like this::
Home allClasses Math Johnny Mary snip...
So how does Math get its list of students? By asking Relations/Classes/Math what students it contains? Now about managing the relations... Can you talk me through an example? What happens if e.g. Johnny drops out of Math? Or if Johnny drops out of school? Or if Math is cancelled permanently? etc... All this is handled through methods of the Relations object? I can see that this helps cohesion and reduces coupling, because all the relationships are managed by Relations and nothing else even knows about them. That's good. And fewer methods need to be added to create a new relationship.
You could also change the view of the site without moving objects around.
Very nice.
Btw. Zope's power is certainly in the ZODB. You just have to use it in a more disciplined manner than you first get the impression of.
So you'd recommend against using SQL? I've yet to really tackle the SQL beast, ZODB has been fine for my web projects so far... -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"