Calvin Hendryx-Parker loves the ZODB. As well he should — it’s an amazing database that continues to be waaay ahead of its time. Object databases are great for content management, it’s a shame to see so many folks stuck in SQL-only modes of thinking.
This is so very true, Jon. In my experience, projects that are SQL-based often suffer from bad architecture, probably because developers are having to think too much about how to store their data.
One downside of the ZODB is that there isn’t a strict mode in which you can formally require data to be of a certain kind. There’s some room for hard-to-track errors there, but it can be alleviated by writing good tests.
If you only store numbers and text in the ZODB and use cataloguing with care (e.g. unlike Plone), it’s very hard to beat the ZODB. There are some downsides (non-standard, questionable scaling, doesn’t like writing too much) and you need to be aware of these.
Plone really abuses the ZODB and it’s a shame, because it’s needless. With better datastructures, leaner objects and a minimum of thought, Plone and ZODB could live in perfect harmony.
+1.
And Malthe, we’re well aware that we’re abusing the ZODB, but “we were young and needed the money.”
I know we’re planning to clean up a lot of this in the near future, so your comments/suggestions/patches are always welcome.
If you mean Plone as in Zope2/CMF/Archetypes/ATContentTypes/Plone
I agree with Malthe. But if we are lucky (and contribute) some of this might get better with Plone 4 already.