About having all the data in ZODB, I tend to agree with Jacob Singh. It is lot more *easier* in SQL (for people who know SQL a little bit) to extract data out in any way you want. However, I certainly don't agree that it is easier to program and maintain ASP/PHP code to talk to database for building a large scale applications - when compared to Zope. IMO, Zope with ZSQL methods is the best and most versatile choice for hooking up a database to web. So, what I tend to do often is to design a database in RDBMS and use Zope to talk to it - this is a hell lot more easier than mixed HTML + ASP/PHP code - it cut down the development time by around 80% and certainly cut down lot of maintenance time. One issue I can think of ZODB is that mass update of properties is little harder than SQL - I know there is find & replace support now, but I've not used it yet - as opposed to simple UPDATE table SET col='' WHERE blah blah. That said, here is the principle that I've been following so far: - If we need only a web application, go with Zope and its products - If we need a web application and that data probably needs to be used elsewhere, create a SQL schema that supports Zope's products. Then automatically synch the ZODB data to RDBMS (well, this will limit the object capabilities of Zope a little bit) - If it is really a mission critical application for which web is just one interface (and it is possible that people want OLTP capabilities later), start with a database design, use ZSQL, preferably make your own management interface and then create ZODB objects from the database. This is a lot like traditional ASP/PHP programming, but you would be surprised how easy it is in Zope. You might want to check the DBObjects product as well. S Babu http://vsbabu.org/