When Does ODB Run Out of Steam?
I have a client who has an application he wants me to build. I'm going to use Zope. The question is whether I should use the built-in object database or an SQL database. I _vastlly_ prefer the former; I tend to think in objects. Each client object in the system has potentially 350 separate properties. These are entered, reported, and managed through a series of about 12 forms. Some of the forms can be used by the client to create multiple entries of the same type. 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. (I'm using MetaPublisher to create the interface and the objects if that makes any difference, though I'd be OK with not using it if it turned out that it had a limit.) -- Hire a world-class ghostwriter to create your entire information product line! Dan Shafer, author of 57 books (and counting) - Ghostwriting Unlimited, Inc. dan@gui.com - 831-643-0590 (V) - 831-401-2531 (F) http://www.gui.com
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
Dan Shafer writes:
I have a client who has an application he wants me to build. I'm going to use Zope. The question is whether I should use the built-in object database or an SQL database. I _vastlly_ prefer the former; I tend to think in objects.
Each client object in the system has potentially 350 separate properties. These are entered, reported, and managed through a series of about 12 forms. Some of the forms can be used by the client to create multiple entries of the same type. This may make for quite large objects...
Note, that properties are not persistent objects but belong to the direct content of their object. When you reference the object, the complete direct content is swapped in (if it is not already in the cache). Depending on the size of your properties, this may become a performance problem. When you use a relational database, you may probably access only the properties actually used for the current application. Dieter
participants (3)
-
Chris McDonough -
Dan Shafer -
Dieter Maurer