On Wednesday 20 September 2006 09:53, [EMAIL PROTECTED] wrote: > Horst, I'm unsure what you mean here: are you refer to program code > modularity or data aggregation size. The latter is what I was referring to > in my previous emails.
I don't worry about data aggregation size in this context. I worry about referential integrity and concurrent access issues. Let us say three users need to concurrently access a "file". The user interface cannot know whether there is any intent of modifying data or not. In a non-atomic document-centric data storage, you would have to "lock" the complete "file" for all other users as soon as the first user does the first "document" manipulation other than just reading it. In an atomic data model, you only need to lock the individual component (single "column" or a single "record") inorder to allow safe concurrent read/write access Common situation in my practice: - my practice nurse just did a few on-site tests (e.g. INR, BSL, Hb, urinalysis) plus a few observations (BP, Spirometry, ECG, weight ...). She starts entering the data while - the patient is already transferred to my rooms and I start entering history, examination findings at the same time - while my secretary is just in the process of scanning in multiple dopcuments for the same patient - and the pathology downloading module simultaneously keeps adding test results that have just been received for that very patient May not happen every hour or every day, but in even a small practice like mine this is likely to happen at least weekly. How do you handle such concurrent data access in a document centric storage model, eg native "full document" XML database? (Unless you have just middle ware emulatiing a virtual document while in the background you have a relational storage engine plucking the document apart and keeping it "valid" in real time by two way communication with your middle ware)? Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
