I can see exactly how to architect this. But my question -- which I can't seem to find an answer to -- is whether there's a practical limit (or a built-in limit) on the number of properties an object can/should have in the Zope built-in object database.
There is a multiterabyte built-in limit for a single ZODB. The practical limit is so large that I don't think anyone can claim they've actually run in to it. Size really isn't an issue. If you use FileStorage, make sure to put the FileStorage on a partition which supports large files. If you use a different kind of storage, keep the same advice in mind. However, the ZODB can potentially perform suboptimally in situations where the chance of simultaneous writes to a particular object is very great (like a counter, or an object that gets updated on every visit on every page). Even this can be avoided with careful coding using application-level conflict resolution, although I suspect many folks would find it easier to use a relational database under this circumstance than to do the necessary voodoo to avoid write conflicts using the ZODB. For more info about write conflicts and app-level conflict resolution, see http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution . You've got to weigh this against the potential gain in productivity that comes by using the ZODB in your particular domain to decide whether it makes sense to use a relational database for your application. - C