[Tutor] Python DB

paul brian paul1brian at gmail.com
Thu Sep 22 18:46:17 CEST 2005

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
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

On 9/22/05, Matt Williams <matthew.williams at cancer.org.uk> 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 at python.org
> http://mail.python.org/mailman/listinfo/tutor

Paul Brian
m. 07875 074 534
t. 0208 352 1741

More information about the Tutor mailing list