Archetype relational mapping - a practical openEHR persistence solution

Seref Arikan serefarikan at kurumsalteknoloji.com
Tue Feb 16 06:26:03 EST 2016


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.beale at 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 at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160216/115f0813/attachment-0002.html>


More information about the openEHR-technical mailing list