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
