[Zope3-dev] Florent's O-R blog entry

[Gary Poster]

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

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

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

Gary