The Zope way of storing data
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
If you're new to zope but have rdbms skills, you might want to think about using a rdbms as the backend and use zope as the interface for it. Most commercial/open source databases have Zope adaptors written for them. Hope this helps. Todd ----- Original Message ----- From: Jens Wolk <jewo_lists@gmx.de> To: <zope@zope.org> Sent: Sunday, January 06, 2002 10:10 AM Subject: [Zope] The Zope way of storing data
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
_______________________________________________ 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 )
Hi Todd, Am Sonntag, 6. Januar 2002 19:39 schrieben Sie:
If you're new to zope but have rdbms skills, you might want to think about using a rdbms as the backend and use zope as the interface for it.
This is indeed a possible solution I consider. But is it really the lack of RDBMSs skills that led to OO Databases? SCNR ;-> I am eager to learn how to model data in a OO database and then decide what better fits our needs. Yours. Jens
Hi Jens, You might want to read http://www.zope.org/Documentation/Articles/ZODB1 if you haven't done so yet, but it gives some of the more technical aspects of the ZODB. Cheers, T ----- Original Message ----- From: Jens Wolk <jewo_lists@gmx.de> To: <zope@zope.org> Sent: Sunday, January 06, 2002 12:54 PM Subject: Re: [Zope] The Zope way of storing data
Hi Todd,
Am Sonntag, 6. Januar 2002 19:39 schrieben Sie:
If you're new to zope but have rdbms skills, you might want to think about using a rdbms as the backend and use zope as the interface for it.
This is indeed a possible solution I consider. But is it really the lack of RDBMSs skills that led to OO Databases?
SCNR ;->
I am eager to learn how to model data in a OO database and then decide what better fits our needs.
Yours. Jens
_______________________________________________ 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 )
participants (2)
-
Jens Wolk -
Todd Graham