[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Questions re database schema - naming

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Questions re database schema - naming
Date: Tue, 31 Aug 2004 11:16:44 +0200
User-agent: Mutt/

> --------------------
> One of my pet hates is not being able to find my way around a database 
> quickly, especially with the passage of time.
Good naming is valuable. We have that laid down in our
Development Guidelines.

> Imagine the following scenario. At the moment gnuMed (yet in its infancy) has 
> in only a tiny part of the database over 160 tables, which read like a dogs 
> breakfast. We should be aiming to visually keep all similar data together ie 

> same sort of object heirachy that one should be using in descriptive terms in 
> the python code:
> eg    demographics_country
typing "demographics_*" is
 a) simply too verbose even for me
 b) will break the object name length limit tomorrow

>       demographics_suburbs (or my hated urb)
Why "hated urb" ?

>       demographics_lu_countries or .. lu_countries
lu_countries, if so

>       demographics_lu_streets    or .,.lu_streets
Not a lookup ! See Horst's comment on what happens when city A
decides to rename street B while city C also has a street B.

Unless, of course, we adopt the rule to not rename a street in
an address but rather relink to a different/possibly new
entry. Which is a design decision.

>       demogaphics_address_data_info (whatever that table is)
Well, it is *your* table, no ?

>       demographics_persons_data_names
>       demographics_persons_lu_occupations
>       demographics_persons_lu_maritalstatus
You cannot have names that long and handle them gracefully.

> Why do I argue for this

>       come to  address (at the top)
>                      scroll a while....
>                                names (of what)
>                     state (of what - matter!!!!!), etc etc
This is not good, I agree.

>       view_person_firstname_lastname (not v_basic_person which gives no clue 
> to 
way too long



link tables:


suggestion, true lookup tables:


GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]