[Zope-dev] relations in objects

[Leonardo Rochael Almeida]

On Fri, 2003-10-10 at 00:46, Jason Corbett wrote:
> Thanks for your reply.  I've actually been thinking in
> an object oriented form for a while.  I've looked at
> implimenting this project in Java using either
> prevailance or a object persistence model that mapped
> to a RDBMS.  I like the idea of zope, so maybe I
> should clarify my question:
> 
> How does an object in zope know where it sits in the
> hirearchy, and how does it reach other objects. 
> That's what I'm really looking for, I can probably
> code the rest of the parts.

In my experience, you should put an object inside another if and only if
they have an explicit containment relationship, e.g. a car has 4 tires
and a steering wheel. The steering wheel can belong to (at most) one car
at any moment in time, so it would make sense to put the steering wheel
object inside the car object. The same is not true of, for instance,
students and school classes. In this case you either store a reference
to the student in the school class (eg a student id in a "lines" or
"tokens" property) or you create an object to represent the
class-student relationship (for example an enrollment) and store it
somewhere.

Tip: always use methods that return the objects you need, for instance
aSchoolClass.students() this way you can more easily change the storage
of the relationship information when you change your mind. And you will
change your mind a lot of times.

Tip2: a lot of times you'll implement the above mentioned methods as
catalog queries, like: what objects in the other side of the
relationship reference me?

Tip3: look mxmRelations

Cheers, Leo

PS: just because this is a pet peeve of mine, I'll explain that a
"relation" and a "relationship" are two very different things.
"Relation" is the mathematical term for a table, a set of distinct
elements (rows) with the same kinds of attributes (columns). You can
think of a relation (table) of cars, or a relation (table) of students.
Relational databases get their names because they store relations and
allow you to do some relational algebra with (usually) SQL.

A relationship, on the other hand, is a link, or association, between
elements.

RDBs allow you to model relationships relatively easily thru either
relational operations:

        SELECT * from cars, steering_wheels
        WHERE steering_wheels.carId = car.carId AND
            steering_wheels.wheelType = "sport"

or by storing relationship information in relations (sometimes known as
"link relations" or "link tables"):

        SELECT * from enrollments, classes, students
        WHERE classes.classId = enrollments.classId AND
            enrollments.studentId = students.studentId AND
            students.studentName = "Jason Corbett"

But RDBs themselves have absolutely no concept of "relationships".

So, next time you read the word "relation", think "table" :-)