Hermann Himmelbauer wrote:
I'm no expert, but I don't see how transactions would lead to a huge database.
I suspect he is referring to the way FileStorage use an append-only file
format (between packs). If you never pack the database, it will grow
forever. The simple answer is "don't do that". :)
This can be an issue if you have a very, very high number of writes of
large objects. The DB may grow too fast between packs to be usable.
That doesn't normally happen though.
When it comes to differences between ZODB and RDBs, I'd say the following:
- In many situations you already have an existing RDB, so the decision has
already been made.
True enough. As you mention below, in this situation you can also use
the ZODB alongside a relation DB.
- RDBs scale scale very well, so in case your application gets really huge, an
RDB is an option. With Zope, you can easily cluster the application server,
however the ZODB can not be distributed. (Maybe ZODB can even not make good
use of multiple processor due to Python's GIL).
They may well exist, but I have yet to see a storage server that was CPU
bound (that wasn't running on antique hardware). IO is much more
important on a storage server (ZODB or RDB).
- In case of data models, which heavily rely on references (=relations), I
think you are also better off with RDBs.
- RDBs have several addons, such as backup strategies, report generation etc.
True, although I've never gotten much value out of "generic" RDB
utilities, especially report generators.
If speed and the data model is not an issue, then I'd opt for ZODB.
If speed is an issue, one rule overrides all: benchmark and then decide.
Moreover there's also the possibility of a hybrid approach, where parts of the
data are stored in the ZODB and other parts in a relational database.
That's my preferred general approach. If data is "painfully
rectangular", then a RDB might be the best approach.
Senior Software Engineer
Zope3-users mailing list