Re: [Gnumed-devel] gmClinical.sql and general comments

[Richard Terry]

> There is no such thing as "sit together" in relational
> databases. Operating with such concepts bears the danger of
> misunderstanding RDBMSs.

You mis-understand my comment. Of course there is not. However if you have one 
hundred tables, and you are working on the vaccination section, and you have 
to keep scrolling up and down a large list were one table is called 
link_vacciantion.. bal bal, the next is called
schedule_vaccines bla bla , the next is called

vacc_dowhatver,, you have to keep moving up and down to find them to work on 
them.

If you aggregate the names again, like I suggested with the file names as gm + 
schema + table + etc. they are easier to find.

ie
vaccination_data
vaccination_lu_vaccines_ in_schedules
vaccination_lu_vaccines
vaccination_lu_schedules
vaccination_lu_vaccine_indications

etc
Though I've not put these in alphabetical order here, they sort so in the 
database tools when you are using them (Ah!!!, Light bulb goes on....  I see 
now, you don't use database tools so it is of no consequence to you!!!, but 
for those of us who do (like moi) it increases my productivity 100 fold. 

In the last two weeks using thes tools I have:

*taught myself elemental postgres (am up to functions which I've not 
understood or mastered

*created a 40gig full product information database, populated it with data, 
done sqls to bring out the text for formatting into html

*created 10gig prescribing database populated with upto date data

*created contacts database and populated with dummy data

*created coding database populated with complete data

*imported most of gnumed by hand so I can get the gist of 
hat it is doing (havn't achieved that yet)

*linked coding database to the wxPython gui and can bring up lists of terms in 
real time in list boxes for selection by the patient

without such gui-tools I wouldn't get to first base, so humour me.




> To understand the database structure - as in how it is
> interrelated - one is supposed to generate an ER model
> representation. Either explicitely - as we provide on the
> Wiki as a PNG - or implicitely in one's head - which I have
> done for too long.

Yes, you can't hold it all in your head. I've used tools like I think from 
memory case studio to generate ER models in the last couple of weeks, and I 
can save and print out complex table relationships for queries (like in my 
contacts db where there are 10-15 linked tables to bring up a single name)


Regards

Richard