Sorry for taking so long to answer -I have away for 4 days Quoting Horst Herb <[EMAIL PROTECTED]>:
> 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 At this point the nurse has to change 2 records -remove the data from the wrong patient document and insert the data into the right patient document. As a new document is generared with each visit that implies an encounter document has been created incorrectly for a patient who didn't have an encounter, hence that "document" has to be removed and a new document for the encounter that did occur created and the blood pressure inserted. > -> 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) The GP will see the encounter document created by the nurse, he can believe the BP taken by the nurse or take his own as an addition or as a replacement and insert that into the encounter document. > > 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 This appears to be a fault introduced by applying a subsumption hierarchy (parent to child) and then independently attaching the inherited features and then not providing a mechanism for undoing inheritance. That appears to be a failure to appreciate the nature of the delete/undo function and its impact on a subsumption hierarchy - it is independent of the IS design philosophy, that is relational vs document strategy. The programming weakness in the example you give appears to be that inheritance has been done by value and not be reference. The undo in this case would behave perfectly sensibly if it was by reference. > > 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. It may be the case that the programmers have not given enough thought to issues of undoing data write which is not a direct inverse if their is a subsequent computation. Jon > > 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 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
