[Zope] Are products the right approach?

[nwingfield at che-llp.com]

Carsten -

> 1) Should Equipment and SparePart be classes or perhaps instead tables in
my
> RDBMS? (ATM they are classes to facilitate the history/undo functionality
in
> Zope)

I have found Zope's undo feature to be highly unreliable.  Just perform a
couple operations in sequence, then try to undo the first operation.  In my
experience Zope throws up its hands and says "I forgot where I put that..."
If you want this feature you'll have to do it yourself.

> 2) Should I make it all as classes (including the Log)?

My only suggestion would be to use either RDBMS or ZODB exclusively.
Suppose it comes time to restore from backups.  How will you know if your
ZODB backups are in sync with your SQL backups?  It could be tricky.

> 3) How do you make relations between objects in Zope? (For use in eg.
> reporting)

Check out the ZCatalog.  For heavy duty reporting, though, you can't beat
relational databases.

One final remark on classes:  using the ZODB gives you a lot more
flexibility in modeling physical objects (Equipment, Spare Parts). If I
were to use Zope classes, I would try to create a class that is far more
flexible, perhaps an "Inventory" class that can behave as any type of
inventory.  I might even create an "Inventory Type" class that contains
information about the various inventory types (maybe the TV people can even
add their own inventory types with some well-designed web methods).  If you
think in terms of a theatre production, you could treat these two classes
as actor and director.  There may be lots of actors in a production, but
only one director (at the root) that tells each actor how to behave
depending on their role they have been assigned.  I've used this model very
effectively in my own development.

- Nathaniel