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