Horst Herb wrote:
> On Thu, 29 Dec 2005 11:53, [EMAIL PROTECTED] wrote:
> 
>>Having sunk countless hours into this and have very little to show for it,
>>personally I'm convinced there must be a better way.
> 
> 
> The way I took / am taking with mini-gnumed is as follows:
> 
> the problems / situation:
> 1.) fully normalized tables proved to be too unwieldly / slow for some 
> purposes - e.g. selecting patients from a list box after entering a name, and 
> you want some demograpohic details (name, age, dob, street, town ...) display 
> in the selector box
> 
> 2.) denormalized tables can be a pain in the butt when updating data & trying 
> to keep data consistent, but are very easy for reading information quick
> 
> 3.) simulating denormalized tables with updateable views is a bit slow for 
> reading purposes, and most access will be read-only
Does the data in the denormalised tables always need to be up-to-date?
For offering auto-completions for stuff like drugs, disease codes etc., where 
speed is paramount, could you
not re-create the read-only denormalised tables overnight?

For the actual patient data, such as a list of drugs, you would be left with a 
1-way join between the single denormalised
"drugs" table and a "link_patient_to_drug" table, surely that should be fast 
enough?

Ian
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to