I'm a bit on the other side of the fence from most of the rest of the folks who have replied. My take on the matter is that unless you have a very compelling reason or need to use an external RDBMS you should keep everything in Zope.
I'm curious as to how to best find information when storing data in Zope. I come from a RDBMS background, so writing SQL statements to find the data that matches a user's request is a no-brainer for me. I would be interested in how one would store hundreds or thousands of records of data in Zope, and then find just the one or two that match the given criteria. Do you have to iterate through the entire branch of the ZODB, or is there another, simpler way that I'm missing?
As mentioned previously, if you're really doing that, then you go ZCatalog. However, sometimes (or often, depending on your problem domain) you can exploit the properties of the object database to make your searching implicit. For example, a directory (like ODP [dmoz.com] or Yahoo) implemented in relational data would endlessly be asked to find things with a certain category key or in a certain range. Or maybe you'd be doing some clever joining or whatnot. In Zope you could use containment to store relationships and position, and forthe contents of a certain category list the contents of that container rather than finding all rows with that container's key. Applications like this are pretty common in web apps. However, if your application really is a great flat pool of data, with a bunch of highly variable mostly arbitrary searches, then you may consider using an RDBMS. That is, after all, what they're really good at doing. Just be sure that the way you think your data domain is structured really is how it should be structured. --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."