I would look quite seriously at SQLObject It is a bit rough round the edges but given a class defintion, it then creates the underlying SQL tables and handles the CRUD (create update delete) for you.
I do not like this approach and prefer the other but equally nice ability it has to look at a database and create appropriate classes, which you can then use. It is a class of Object Relational mapper, of which there are a few Java production level ones but I do not know of any "real world" uses of SQL Object. Perhaps others do. Backups and access from other applications imply you want a fairly serious admin load afterwarss - in which case I would think very carefully before using anything other than a "real" RDBMS (Oracle, MySQL, Postgres MSAccess even). Backups and synchronous access are what they are designed to do. However are you quite sure a normal db table will not suffice - I tend to find that the underlying data structure is never as fluid as one suspects. Patient - disease - treatment sounds a fairly striaghtforward domain. Perhaps if you shared a few things that make you worried it will change dramatically someone might be able to suggest workable structures. On 9/22/05, Matt Williams <[EMAIL PROTECTED]> wrote: > Dear List, > > Thanks for all the advice! Obviously, I'm still a bit torn, but some of > the ideas looked good. > > In terms of spec, the DB can be fairly simple (single access, etc.). > Lower dependency on other libraries is good. Also, it needs to be cross- > platform. > > The problem (I have) with SQL-type DB is that I cannot be sure ahead of > time of the exact data structure. The DB will be about patients, who > have diseases, and also have treatments.....Clearly, I can't specify now > the exact structure of the table. The advantage of SQL is that you can > (in general) do things like constrain types for fields, and give > enumerated options, which makes the data more consistent. > > The thing I liked about KirbyBase was that it used text files. This is a > real advantage, as it means that I can access the data from other > application easily, and also makes it easier to back-up (can just copy a > few files). The same would seem to be true of the XML-based options. The > advantage of ZODB was that the "object" structure seemed to map well to > the concept of patients, with diseases, with treatments, etc. (and > Shelve would work at least as a trial implementation) > > The final thing is that I needs to have a simple GUI frontend. The nice > thing about ZODB is that I could just map the eventhandlers to functions > on objects.. > > If people have more comments in the light of the bigger spec. above, I'd > still love to hear them... > > Matt > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > -- -------------------------- Paul Brian m. 07875 074 534 t. 0208 352 1741 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor