On Aug 24, 2005, at 8:08 AM, Lennart Regebro wrote:

I'm not convinced that Florent blog entry says what Gary thinks it

Hopefully you can see where I would get my interpretation, though. I'm happy to have Florent clarify on his return. This is a good discussion in any case.

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,

Well, I didn't say that, actually. I said that Btrees are excellent tools; neither they, nor the Zope 3 catalog are hacks; and the pure ZODB catalog story has compelling advantages over an RDBMS catalog, in addition to disadvantages.

but it is data like that that
relational databases are sepcialized to handle. For HUGE catalogs,
installing a dedictaed relational database makes sense.

I can imagine situations in which this might be true, yes. That said, BTrees are excellent for huge data sets. Fixing the ZODB cache story would be a big step to making them even better.

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
database. :-)

I suppose. This doesn't strike me as hugely compelling--until someone explains to me why it wouldn't be, it seems like it would be easy to implement these sorts of features efficiently in a ZODB-based catalog if someone cared enough.

Again, my argument is not against O/R mappings, it is on relying on them exclusively for a shared platform. I'm *very* happy to have us leverage the component architecture to have different component implementations for different use cases. That, of course, makes plenty of sense, and is at the heart of Zope 3.

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.

Sounds good.

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).

Absolutely. RDBMS should be one option for that sort of use case, as should rotated flat files, probably. We've used both, for different use cases.

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
relational database.

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.

Cool. I'll expand your summary of my email to say that a relational database should not be required for a shared "enterprise CMS" project, but RDBMS-based components, and transparent O/R backends like Ape, should be configurable options. From other parts of your mail, it seems you might agree with that too. I hope so.

I would be happy to agree with your interpretation of Florent's blog, given the caveats from my message, as you and I summarize them here. Some of Florent's blog is worded in such a way as to make me wonder if your interpretation is accurate, though. :-)

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to