On Wednesday 20 September 2006 17:00, [EMAIL PROTECTED] wrote: > In terms of entering data for the wrong patient I'm not sure what > referential integrity you want to preserve. Clearly the data has to be > taken out of one episode and possibly the whole episode removed as it was > allocated to the wrong patient.
My example suggested that 1) practice nurse records BP in her "encounter document" 2) GP references that BP record in his "encounter document" 3) nurse realizes she made a mistake, reading was somebody elses, and corrects that record -> what will happen to the GPs reference to the previous record that is now corrected ? (without manually going through the records and searching for broken references which really nobody ever should be expected to do) Or, a real world example that plagued a commercial record system: 1) some doctor records a patient's past history incorrectly 2) a parental relationship is entered between this patient and another patient 3) the system thinks it is "smart" and automatically uses the "parent's" past history records as "family history" record entries for the "child" - but not by referencing these records, but by copying thesze entries into the "family history table" 4) somebody realizes that the past history of the parent is incorrect and corrects the entry -> now I have conflicting information in my record system; the child's record now still contains an incorrect entry, but in all likelihood nobody will find out in a hurry I mentioned Andrew Ho's OIO system before - that kind of referential integrity problem is this systen's Achilles heel. I like document centric data storage because it makes import/export/merging so much easier than atomic data storage - but I don't know how to overcome this problem without some very sophisticated "data maintenance daemons" or a trigger based integrity preserving system The whole point of modern ACID compliant data stores is that application software developers don't have to construct very extensive and sophisticated middle ware any more just to preserve such referential integrity - the backend does it automagically. However, with document centric data stores I still haven't found one that would fulfill the classic criteria of ACID ... unless the backend is not really a document centric store after all, but a relational database using a front end that constructs/deconstructs e.g. XML documents on the fly (e.g. Berkeley DB-XML) - which makes document insertion and updating painfully slow even under modest load Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
