You're right, it does not read in the way I wanted it to. Let me try to clarify:
Clinical care is strongly single patient centric, and in most cases this puts a limit on the amount of data that does not push the limits of computational power too much. Developers can afford to fetch multiple documents and go across them if needed without requiring the DB to perform the same operation, hence having to process XML (or json) So you can get away with treating the relational database as a document store and performance problems do not easily reveal themselves. There will be cases which this won't work (for a single patient's care), but it is only when the requirement to produce time series, aggregates etc becomes too expensive to do outside of the DB. Even then, most implementations would pre-define these and populate them during data entry in advance, and still get away with not having to dissect XML at the db level. So my argument is more about being able to not to process XML using the relational database than the necessity of clinical data that spans multiple documents, which can be summarized as "developers are lazy" Does it make sense now? On Tue, Feb 16, 2016 at 11:33 AM, Ian McNicoll <i...@freshehr.com> wrote: > Hi Seref, > > "so there is rarely a requirement to read across documents, because > clinicians would not be able to consume all that information at once > (except averages or other aggregate values they're interested in)" > > I don't think that is true in any other than the most trivial > implementations. The ability to query and pull granular data across > documents, for single and multiple patients is a critical requirement for > anty EPR/EHR. > > or perhaps I misunderstood? > > Ian > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > On 16 February 2016 at 11:26, Seref Arikan < > serefari...@kurumsalteknoloji.com> wrote: > >> The document oriented view of the domain has no problem with storing XML >> text in the DB, because the implementations are built against that view. >> The clinical care focused use cases require developers to focus on reading >> & writing documents, so there is rarely a requirement to read across >> documents, because clinicians would not be able to consume all that >> information at once (except averages or other aggregate values they're >> interested in) >> >> So developers mostly deal with put document/get document type of >> requirements and simply having an XML field (or json for that matter) makes >> things easy for them. Hence, it makes sense to them. Database vendors have >> their own reasons for supporting direct storage of XML and they deal with >> obvious disadvantages behind the scenes (google: postgres xml toast). The >> price of storage keeps falling faster than all the other components,which >> also helps justify this approach. >> >> I suggest a coding exercise for representing XML documents in a >> relational database with writes and reads to see what a joy it is to >> rebuild an XML document in comparison to just reading it directly from a >> column :) >> >> Some DBs store XML using tables behind the scenes to save the developers >> from this pain, but they usually rely on schemas to do that (cough **rcl*) >> and it becomes another joyful activity to use that feature. >> >> So all I'm saying is: there is a price for everything, and in some cases >> having xml sitting in the db is not as bad as it sounds >> >> On Tue, Feb 16, 2016 at 10:47 AM, Thomas Beale <thomas.be...@openehr.org> >> wrote: >> >>> >>> >>> On 14/02/2016 23:25, Bert Verhees wrote: >>> >>> One doesn't know what software really does. One must distinguish what >>> software seems to do and what it really does. >>> >>> Storing XML really as XML means, storing a lot of redundant information. >>> I don't know, but I cannot believe postgress really stores the full tag >>> names, even when they occur thousand times. I would be really disappointed >>> if they do. >>> >>> Bert >>> >>> >>> storing a text serialisation of an object structure in a database never >>> makes sense when you think about it. Storing a *binary* serialisation >>> is a normal 'blob' approach, and if you are not doing blobs or partial >>> blobs, then you are doing transparent representation, in which case things >>> like XML or JSON don't come into it - they only make sense as one kind of >>> generated view on data. >>> >>> You might implement blobs using a zipped text format, but in a serious >>> scalable implementation that would surely have to be the least efficient of >>> viable approaches. >>> >>> I can't think of any circumstance where a DB would actually store its >>> information as XML instance text (other than where some column value >>> happened to be an XMLstring, i.e. the XML is just data). >>> >>> - thomas >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
