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.

Why's that?

- RDBs have several addons, such as backup strategies, report generation etc. 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.
Benji York
Senior Software Engineer
Zope Corporation
Zope3-users mailing list

Reply via email to