[Zope] The Zope way of storing data

[Jens Wolk]

Hello everybody,

I am new to Zope. I have worked with OO Programming Languages before but not 
with OO Databases (only RDBMS's). Therefore the biggest challenge for me is 
to think of non-relational ways of storing data.

In the following I would like to present you a small data modelling problem 
which I am working on right now and ask you to comment on it. It's a 
real-life example.

I am working on "Yellow Pages" Site for a local NGO. I will keep things 
simple, so let's call the site the "Simple Yellow Pages", or SYP for short.

What SYP is
===========

SYP consists categories, entries and contacts.

Categories.
The categories are arranged as a tree (the nodes of a rooted tree). Each 
category has exactly one parent category to which it belongs - except the 
root category which has no parent. A category can in turn have an arbitrary 
number of child categories (zero, one or more).

Entries.
An entry can show up in an arbitrary number of categories. (Categories in 
turn can contain categories *and/or* entries). An entry belongs to exactly 
one contact.

Contacts.
Contacts are persons (outside the system) who are responsible for entries. An 
arbitrary number of entries can be attributed to a contact.

Relational data model
=====================

(you may skip this part if things seem clear to you and are interested in the 
Zope way of modelling only)

In an Entity-Relationship-Diagram we would the have three entities (category, 
entry, contact) and the following relationships:
"is_parent_of"         category - category (1 : *)
"contains"             category - entry    (* : *)
"is_responsible_for"   contact  - entry    (1 : *)

This would lead to the following CREATE TABLE statements (MySQL):

CREATE TABLE category (
  id		INTEGER NOT NULL AUTO_INCREMENT,
  parent_id     INTEGER NOT NULL,
  PRIMARY KEY	(id),
  FOREIGN KEY 	(parend_id) REFERENCES category
);

CREATE TABLE entry (
  id		INTEGER NOT NULL AUTO_INCREMENT,
  contact_id	INTEGER NOT NULL,
  PRIMARY KEY	(id),
  FOREIGN KEY	(contact_id) REFERENCES contact
);

CREATE TABLE contact (
  id		INTEGER NOT NULL AUTO_INCREMENT,
  PRIMARY KEY   (id)
);

CREATE TABLE contains (
  category_id	INTEGER NOT NULL,
  entry_id	INTEGER NOT NULL,
  PRIMARY KEY (category_id, entry_id),
  FOREIGN KEY (category_id) REFERENCES category,
  FOREIGN KEY (entry_id)    REFERENCES entry
);

The most interesting table is the one labeled "contains".

The Zope way of doing it
========================

The categories would be folder objects (a descendant of the ObjectManager 
Class, right?).

The entries would be easy, too, if an entry would be restricted to belong to 
exactly one category. An entry then would be just be a object residing in a 
Category object. (YihawDirectory is an example for this approach.)

But the entries in SYP here indepently of the Category objects. So I would 
create a folder (which is not visible to the public) in which the Entry 
objects lay. The Category objects then would contain some sort of pointers to 
the actual Entry objects.

Deleting a non-empty category wouldn't do any harm because entries are 
allowed to exist without being part of a category. The update of an entry is 
reflected in each category it shows up.

For the contacts, there would be again have to be a special folder which 
contains all the Contact objects. A Entry object then would contain a pointer 
to a contact. But a contact must not be deleted as long there are any Entry 
objects with a reference to the contact. How would I enforce this? (A 
'normal' RDBMS guarantees such relational integrity. MySQL is not a normal 
RDBMS ;-)

The questions
=============

Does this solution for Entry objects (folder with the actual objects, 
pointers to them in the categories) make any sense to you? Somehow, I don't 
feel comfortable with thousands of objects with cryptic keys (ids) laying 
around in a folder. So, there would probably be a need for a smart view on 
these objects.

How can I make sure that a Contact object can not be deleted as long as there 
are references to it?

Your comments are very welcome.

Jens Wolk, Berlin