Martin Aspeli wrote:
I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql.

That depends. If the data is heirarchical, I'd stick with ZODB. IF I cared about seamless rollback I'd stick with ZODB. If I cared about a uniform storage for all data to do with a project, I'd stick with ZODB...

Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need "ad-hoc" queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application.

Yup, not gonna argue with any of that, if only for integrating with legacy systems...


Simplistix - Content Management, Zope & Python Consulting

Zope3-dev mailing list

Reply via email to