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 possible solution I took: 1.) start with denormalized tables to get things going quickly Model the denormalized tables to the needs of the most commonly / frequently user interface elements to facilitate delay-less user interaction (= data model does not follow theoretical ideas about the nature of the data, but it follows the real world interaction the end user will have with the data) 2.) add normalized tables later, with trigger functions in both normalized and denormalized tables doing the housekeeping - wherever needed and appropriate it works and is as fast as it gets, but it is not aesthetically pleasing and not scalable. Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
