[Zope] The Zope way of storing data

[Todd Graham]

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 )
>