I have some opinions on this
My experience years ago was also with an ORM environment, I tried
several. but then I looked at the generated queries.....
This has nothing to do with scalability or good performance. If you want
a system with several hundred simultaneous connections working on it,
then there must be better ways then executing hundred lines SQL.
But it is not an OpenEHR exclusive problem. I went to a HL7v3 meeting,
and they sometimes work with kind of relational databases too.
A software product was proudly demonstrated, it generated SQL statements
from object-oriented statements, they generated statements of 250++ lines.
By the way, they did not know that until I asked them.
Nice debugging if the output is not what you expected. And also, how can
you ever trust an output coming from such an SQL statement? We are
talking about life an death.
In fact some of the big database-vendors work this way too, but they do
it in a professional way, with hundreds of very well trained and highly
qualified developers. And then it is another story.
There are many simplifications that can be done to reach an object
model that is compatible with the openEHR model but more "relational
friendly".
Correct, that is a possibility. For example. each DV_TEXT has two
codephrases, one for language, one for charset. These are minimal two
extra recursive loops in an SQL statement (and then find out that they
contained a null value ;-).
This slows down the queries. As long as it is straight and simple, there
is no problem.
You can ignore those codephrases and say that the language always will
be Chinese or Spanish, and the same for the character set. You can also
optimize them by concatenating the information and put it in a field,
but then you will never be able to query on those values, only in free text.
Or you can say, we only work with these archetypes, and optimize the
database for it, but then it is not anymore two level modeling (or
user-central modeling as I like to call it)
That is part of what I meant with the light version of OpenEHR. Nothing
wrong with that, it can serve purpose. But it is not OpenEHR, it looks
like it.
If I was an hospital manager, I would not rather take a full blown
OpenEHR system, or else go to a monolithic classic hospital system which
does a fine job for many decennial. It is not that people dying fast
when a hospital uses Epic. I saw a classical monolithic system with 7000
tables, and the number growing every day. It runs for over 20 years, it
started with a few hundreds tables. So it grew with 350 tables every year.
In my opinion, it still can run for 20 years more, but spitting in those
7000 tables is impossible (by then, 15000), no one knows what is in it,
many haven't been touched for ten years. No screens connected to them
anymore, no one knows what they do, no one dares to optimize. I have
seen many systems like that. It is a common practice in many companies.
These are not datastorages, but datadumping sites.
Let it grow, let it grow, sings Eric Clapton ;-)
So I believe, that an OpenEHR system is cheaper, better maintainable and
more future prepared then a classic monolithic system, also when that
OpenEHR system uses the most advanced technologies it will be cheaper
and better maintainable.
I have experience with XML-kernels, lets focus on that. OpenEHR is very
easy to process with XML. AQL is easy to convert to XQuery, in fact XML
is more or less object oriented. But XML is only one approach, there are
more ways. I am studying them now.
But regarding to XML, I want to say following:
Oracle 12c, for example, creates underwater a relational database from
an XSD, and stores XML-data in that database, and converts xQuery
(underwater) to SQL on that database. (I believe the Chinese ARM
approach is like this, but then in own development.)
I did not experience the Oracle performance as lightning fast, but maybe
that can become faster by having more machines in a cluster, and doing
some tricks you do not find in books, but you can learn from Oracle,
only if you pay for the license, which is not cheap and you hire some
specialist, which is also not cheap. I am not a trained Oracle engineer.
I know that you need to be to get the best out of Oracle databases.
(By the way, for developers using Oracle it is free, but you work
without bugfixes and without this advanced knowledge which you really
need. )
Another expensive product, which is advertised as faster as Oracle is
MarkLogic. I never tried it, although it is also free for developers. I
believe a license is 32.000 Euro a year, but I don't know if it is for
clusters, etc. I think however, that price is a small beer for a big
hospital.
I don't know how they handle XML underwater, but they do it well, as I
understand. I should try it, but I am busy with other things.
My opinion is, pay what is needed, and go for the best.
Bert
On 26-01-16 02:52, pablo pazos wrote:
ORM is not a problem with current tools. In fact frameworks like
Hibernate and Grails make Object-Relational Mapping something
enjoyable to work with. I think the problem with the described
approach is the growth of the relational schema when your knowledge
base grows.
But there are design challenges, ORM doesn't solve all the problems
itself. IMHO, the object model that should be mapped to relational, if
relational is chosen as DBMS, is not the raw openEHR IM.
Simplifications over the IM are needed in order to prevent excessive
JOINs and huge hierarchies. In fact I teach this in one of my courses
and this was part of the tutorial we did on MEDINFO. For example, the
OBJECT_REFs can be designed as simple relationships, because plays the
role of a FK in the object model. There are many simplifications that
can be done to reach an object model that is compatible with the
openEHR model but more "relational friendly".
--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com <http://cabolabs.com/es/home>
------------------------------------------------------------------------
Date: Mon, 25 Jan 2016 18:42:01 +0100
Subject: Re: Archetype relational mapping - a practical openEHR
persistence solution
From: [email protected]
To: [email protected]
Another problem is you have to convert your object oriented model
(which RM is) to a relational model, which becomes complex in
converting templates/aql to SQL. I have been that way. More then five
years ago I left it. It is difficult doable, if you want a full
featured openehr kernel. I would never recommend going this way,
unless someone has a really smart idea.
It can work for a light featured openehr light derived application model.
Best regards
Bert
Op 25 jan. 2016 15:26 schreef "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>:
I talked about this approach with a colleague from China during
MEDINFO. The problem is your schema grows with your archetypes.
Also, that storing data from many templates that don't use all the
fields in the archetype, will generate sparse tables (lots of null
columns). I told him it was easier to do an ORM from the IM,
because the schema doesn't change and allows to store data from
any archetype/template. But they already have a system working
this way.
Sent from my LG Mobile
------ Original message------
*From: *Ian McNicoll
*Date: *Mon, Jan 25, 2016 10:06
*To: *For openEHR technical discussions;
*Subject:*Archetype relational mapping - a practical openEHR
persistence solution
Interesting paper from China
http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected] <mailto:[email protected]>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
<mailto:[email protected]>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical
mailing list [email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
