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.