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
