I'm not convinced that Florent blog entry says what Gary thinks it
does, but I agree with Gary on the other stuff: It should be possible
by configuration, to switch out at least some parts to a relational
The catalog indexes and metadata is a prime example of this. No, there
is nothing wrong with ZCatalog, but it is data like that that
relational databases are sepcialized to handle. For HUGE catalogs,
installing a dedictaed relational database makes sense.
As Florent pointed out, you may want to do typical aggregational stuff
on meta data I personally thing the right way to o that is by indexing
them in a catalog that supports that, like for example a relation
It would be nice to have some sort of transparent support to choose
how blobs are stored; in the ZODB on disk or in a relational database.
It would be nice to have an easy way for usage statistics to be stored
in a relational database. Storing the in the ZODB is generally not a
good idea (as they tend to make every click a write transaction).
Therefore, I agree with what I think Florent tried to say: An
enterprise CMS needs to have relational integration built in, straight
in the core, so that you can, configuratively store certain data in a
I also agree with what I think Gary is trying to say: We should NOT
try to store as much stuff as possible in a relational database.
Just my 2 centimes.
Zope3-dev mailing list