[Zope] Re: [Zope-dev] Re:

[Phillip J. Eby]

At 08:27 PM 9/27/99 +0300, Hannu Krosing wrote:
>Ping Lau wrote:
>> 
>> In fact, PostgreSQL is my second choice after MySQL.
>> But after reading the
>> ZODB features, I am trying to see whether or not ZODB
>> is suitable for my
>> project.  If it is suitable, I might as well take the
>> advantage of it & save
>> me some works from messing with RDBM.
>
>BTW, have you considered using Gadfly ?
>
>It's actually a quite nice SQL DB.
>
>I don't know if it supports transactions though (I guess not).

Gadfly does support transactions.  However, it keeps tables entirely in
memory.  This can make it blindingly fast for some read-only operations,
but it is much slower when committing transactions if the database is
large.  It is not suited to large DB operations.

The ZODB can work well for DB operations if your queries are amenable to
the ZCatalog model.  However, ZCatalogs are optimal only if you are doing
periodic indexing (rather than up-to-the-minute indexing) of large
databases.  If your application involves frequent changes to indexed
fields, and you use the off-the-shelf FileStorage, your ZODB will grow
rapidly.

It is possible to replace FileStorage with a Storage that would not grow in
this fashion, but also would not support Undo and Versions.  (Look at
'dbmStorage.py' in lib/python/ZODB/ for an example.)  If you don't care
about Undo and Versions, this may be your best bet.  I'm not sure, however,
what level of crash recovery is provided by the dbmStorage object.  E.g.,
if the process is killed during a transaction commit.  FileStorage is very
robust for these kinds of things; I'm not at all sure about gdbm.