[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/1.3.22.1i |
> TABLE NAMING:
> --------------------
> 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
Agree.
> 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
views:
v_*
link tables:
lnk_*
suggestion, true lookup tables:
lu_*
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- Re: [Gnumed-devel] Questions re database schema:street:address:urb:country, (continued)
Re: [Gnumed-devel] Questions re database schema:street:address:urb:country, Ian Haywood, 2004/08/31
Re: [Gnumed-devel] Questions re database schema - naming,
Karsten Hilbert <=
Re: [Gnumed-devel] Questions re database schema - nomenclature, Karsten Hilbert, 2004/08/31
Re: [Gnumed-devel] Questions re database schema - normalization, Karsten Hilbert, 2004/08/31
Re: [Gnumed-devel] Questions re database schema:street:address:urb:country, sjtan, 2004/08/31