Archetype relational mapping - a practical openEHR persistence solution
ian at freshehr.com
Tue Feb 16 06:33:17 EST 2016
"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
or perhaps I misunderstood?
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
email: ian at freshehr.com
Co-Chair, openEHR Foundation ian.mcnicoll at 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 <
serefarikan at 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.beale at openehr.org>
>> 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.
>> 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
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical