[Zope] ZODB/RDBMS newbie question
J Cameron Cooper
Sat, 08 Mar 2003 00:00:49 -0600
>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
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
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.
(with a grain of salt)