[Zope-dev] ZPatterns design questions

[John Eikenberry]

First, some context... I'm working on a new data storage system for a
related set of (primarily) Zope sites. The data will be kept in ZODB and
mirrored out to a RDB (MySQL) to provide read-only access to some non-zope
stuff. One other thing to note, all of this will be done via python code
(no zclasses).

Now say that I want to keep data about a company. I have a specialist, rack
and dataskin already created. I currently can store data on the skin via
AttributeProviders, but this was mainly done to get something working to
mess around with. 

What I think I want is several SheetProviders. Two for each block of data
(a block basically reflect the breakdown of tables in the MySQL DB). Why 2
for each block, one for the ZODB store and one for mirroring the data out
to the RDB. So, the breakdown for the company would look like this:

Company Rack
  - Company Information (name, url, etc). 
    . SheetProvider (ZODB) - read/write
    . SheetProvider (SQL) - write only
  - Address Information (city, state, zip, etc)
    . SheetProvider (ZODB) - read/write
    . SheetProvider (SQL) - write only

Does this sound reasonable? I thought about writing a mix-in class to add
the SQL stuff to the SheetProvider, eliminating the need for 2 entries for
each block of data. But I liked the idea of each being its own plugin,
seemed cleaner.

The specific question I have about this design is where does the
_properties() attribute go? They need to be associated with their
appropriate SheetProviders, so that seems the most likely place, but that
would require a SheetProvider subclass for each data block which bothers
me. It also just doesn't seem to fit in with the design pattern, but my
understanding of it is still fairly limited.


Next Topic... 

Adding to the above design, we add a second entity; People. I need to
express relationships between the people and the companies. These
relationships can be of various sorts; eg. technical contact, marketing
contact, company admin, etc.

My idea is to create another specialist/rack/dataskin to contain the
information about these relationships and associated data (type of
relationship, corresponding roles, references to the related entities, etc). 

I don't have any code for this aspect of the design yet, so I'm only
fishing for general criticisms/thoughts at this point. Is there a better
way to do this? BTW, there are going to be many more types of entities and
relationships that these examples, so it needs to scale. It also needs to
perform well, as the authentication mechanism will be fetching the roles
off the relationships and, possibly, their related objects. 

Thanks in advance for any advice.

-- 

John Eikenberry
[jae@zhar.net - http://zhar.net]
______________________________________________________________
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin