I am curious when I should use ZODB or an RDBMS. For instance, I am writting a little web app to maintain the Sunday school department at my church. I am porting it from a Tcl/Tk app for practice into Zope.
I track Households, People and Classes. Households has many people, and a Class links to the person table twice, once for the teacher, and another time for the substitute.
I am curious if I should be researching using ZODB for this or use an RDBMS?
Well... if you ask me (and after a fashion you did) if you're going to bother using Zope, you might as well use it as it was meant. And that means persistent objects, and that means ZODB. The only really good reason to use an RDBMS in Zope is to interface with existing systems. If they're there and it's either required you use them, or it'll save a heap of time, that's why Zope has SQL capabilities. There are some valid but less convincing reasons to use a RDBMS with Zope: the database system has some exotic feature that you can't get with the ZODB, your application is very well suited to a table-storage architecture, or the developers are trained in relational thinking, and not clued in to Zope and/or objects. The first is getting less true all the time, the second is reasonable but hardly common (in my estimation), and the third, well, it kind of speaks for itself. There used to be some other reasons to abjure from the ZODB: rapidly changing objects conflict with the undo capability, and capacity and stability concerns. The former is easily solved by non-undoable storages (although I think a per-object/product switch for this would be great) or scheduled packing; and the latter isn't much justified today even with FileStorage and especially with fun stuff like Directory Storage. Negatives aside, the ZODB is a good and proven relational database. If you use it, your application will make a lot more sense with regards to Zope's capabilities, and it'll free you from having to deal with another separate system. Of course, all that is high-level stuff. Now to you: It seems you already think in tables. If you're trying to get something specific done quick, play to your strengths. Pretend it's Cold Fusion with a nifty interface. But if this is an exercise in learning Zope, I think it's important that you stay well away from relational databases: I think you'll get a lot more milage out of Zope if you use it in its "native mode". As to the particular application, it can be done either way, but I think if you decide to make it a heap of persistent objects rather than a heap of table records, you're going to have to do a little rethinking about how to actually go about it. --jcc (with a grain of salt)