R: [Zope] Discussion: Best practice site struture (LONG)

[Adam Manock]

Looks like a job for the Entity-Relationship model to me.

Take the example of teachers and classes.

First we note that these are independent entities, ie they can exist 
independently of each other.

So in an RDBMS, we'd end up with a table called called classes, and one 
called teachers, as well as one called class_teacher that expressed the 
relationship of a particular teacher teaching particular class. There would 
be two foreign key attributes in this class_teacher table, this table only 
needs to have two columns to properly relate a teacher to a class.
These two attributes would be foreign key references to the other two 
tables, so that only class / teacher combinations where both the class and 
the teacher exist in their own respective tables would be allowed. The 
benefit you get here is that you can delete the class-teacher relationship 
and still have somewhere to store the class AND the teacher. You can store 
classes that do not yet have teachers, teachers that do not yet have 
classes, etc,  and worry about relating the class to the teacher later.

This kind of analysis of the data set that we want to work with, along with 
the practice of mapping the analysis to tables, attributes and constraints 
is well established in the RDBMS world.
I have yet to get my head around mapping a complicated data set and the 
relationships between the data elements to an object database, like the 
ZODB :-) So, for now at least, the answer is   PostgreSQL, and we use it 
*alot*.

I should probably add that the Zope object tree you create to work with the 
RDBMS data can then reflect what users need to do with the data, rather 
than the data itself. In other words, Use Cases can be met with a 
collection of Zope objects that represent actions that users need to take.

Adam

At 03:05 AM 4/10/02, Max M wrote:
>Paul Winkler wrote:
>
>>Hi Max, this is a VERY interesting thread to me now,
>>very timely.
>
>Great!
>
>>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.
>
>Sound and music ... one of my most favourite topics :-)
>
>>>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?
>
>That isn'r really important at this stage. Just the idea of relating to 
>objects.
>
>>>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?
>
>Yes
>
>>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...
>
>The problem with that is that it really is application specific. You 
>cannot handle these cases generally. There is no way of knowing the right 
>way to act if an object is deleted. It depends on the type of object, it's 
>relations and the application. Sometimes it's also a question of business 
>process. Some company might have added an extension that needs a copy of 
>the object to stay around so it isn't really delete but just marked as 
>inactive. Other companies might just delete those objects. etc.
>
>You should use "manage_beforeDelete()" to handle these cases. It is called 
>by Zope before an object is deleted if the object has the method implemented.
>
>>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.
>
>Exactly
>
>>>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...
>
>I would certainly not recommend against using SQL, but even thought I am 
>an experienced user of SQL I hardly ever use it in Zope. The 
>object/relational impedance mismatch is simply to annoying ;-) But it has 
>probably also something to do with the type of apps I write.
>
>regards Max M
>
>
>
>_______________________________________________
>Zope maillist  -  Zope@zope.org
>http://lists.zope.org/mailman/listinfo/zope
>**   No cross posts or HTML encoding!  **
>(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
>http://lists.zope.org/mailman/listinfo/zope-dev )