Aw: Re: Archetype relational mapping - a practical openEHR persistence solution

> If a database has a field-type XML, then I expect it does something special > with > that field that justifies the fieldtypename. Oh, it does, it offers validation of the XML, AFAICT. Karsten Hilbert ___ openEHR-technical mailing list

Re: Archetype relational mapping - a practical openEHR persistence solution

If a database has a field-type XML, then I expect it does something special with that field that justifies the fieldtypename. Especially I expect that from Postgres, because they mostly do good things. Bert On 16-02-16 11:47, Thomas Beale wrote: On 14/02/2016 23:25, Bert Verhees wrote:

Re: Archetype relational mapping - a practical openEHR persistence solution

On 16/02/2016 11:26, Seref Arikan 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

Re: Archetype relational mapping - a practical openEHR persistence solution

You're right, it does not read in the way I wanted it to. Let me try to clarify: Clinical care is strongly single patient centric, and in most cases this puts a limit on the amount of data that does not push the limits of computational power too much. Developers can afford to fetch multiple

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

On Sun, Feb 14, 2016 at 12:01:55PM +0100, Bert Verhees wrote: > I don't believe that XML-databases actually store XML. Oracle, for example, > breaks it up in a relational structure. But I don't know the internals of > others well. The worst solution, however for storing XML would be really >

Re: Archetype relational mapping - a practical openEHR persistence solution

Thanks, I always forget it is weekend, as independent developer, there ain't no such thing as a day of. I agree that mixing query-languages is ugly, and I don't see the necessity. But maybe, you will explain that next week Bert On 13-02-16 17:46, Birger Haarbrandt wrote: Hi Bert, I will

Re: Archetype relational mapping - a practical openEHR persistence solution

Even as a research associate or independent developer, its sometimes good to take a break from work :) I hope I didn't miss a point in your e-mail and hope that I understood corretly: when you store openEHR-data using XML technologies, you will have to use XML technologies to query that data.

Re: Archetype relational mapping - a practical openEHR persistence solution

On 13-02-16 18:13, Birger Haarbrandt wrote: Even as a research associate or independent developer, its sometimes good to take a break from work :) I hope I didn't miss a point in your e-mail and hope that I understood corretly: when you store openEHR-data using XML technologies, you will have

Re: Archetype relational mapping - a practical openEHR persistence solution

Thanks, My feelings for postgresql are well known, it is a great piece of code. Final question, do you support AQL with your current design? On Tue, Jan 26, 2016 at 10:40 AM, Jan-Marc Verlinden < jan-m...@medvision360.com> wrote: > Hi Seref, > > We tested with lots of queries, not with large

Re: Archetype relational mapping - a practical openEHR persistence solution

I have not performance tested my own implementation (although I did actually build one over a decade ago). But the Informix path system was real and performant (they used a hierachical number node code approach e.g. 1.2.3, 1.2.3.1.2 etc). There are others I have read about as well, but I'd

Re: Archetype relational mapping - a practical openEHR persistence solution

Thanks for the answers Jan-Marc. On Tue, Jan 26, 2016 at 11:55 AM, Jan-Marc Verlinden < jan-m...@medvision360.com> wrote: > Dear Seref, > > At moment we do not support AQL, mainly because none of our current > partners/developers are asking for it. We have discussed using AQL > internally

Re: Archetype relational mapping - a practical openEHR persistence solution

We haven't convert RM to relational model, it will cause lots of JOIN operation and low performance. Actually, we using "storage template", which is a specialization of archetype for storage purpose, and is generated automatically according to existing multiple templates (If more templates are

Re: Archetype relational mapping - a practical openEHR persistence solution

Hi Thomas, *this is also what I would expect. Path-based storage does rely on very smart ways to figure match terms in a query to paths of course.* Did you test, or is this theoretical? Jan-Marc Op di 26 jan. 2016 om 11:36 schreef Thomas Beale : > > > On 26/01/2016

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 10:15, 吕旭东 wrote: We haven't convert RM to relational model, it will cause lots of JOIN operation and low performance. Actually, we using "storage template", which is a specialization of archetype for storage purpose, and is generated automatically according to existing multiple

Re: Archetype relational mapping - a practical openEHR persistence solution

Hi Jan-Marc, To clarify: when you say huge: do you mean that the result set is huge, or the the amount of existing data is huge? Are you able to comment on how query performance changes/stays the same when the result set size begins to grow? On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden <

Re: Archetype relational mapping - a practical openEHR persistence solution

Dear Seref, At moment we do not support AQL, mainly because none of our current partners/developers are asking for it. We have discussed using AQL internally several (lots of-) times, but also with for instance Ian. If this changes, so if there is a need for AQL, we could easily support it. Its

Re: Archetype relational mapping - a practical openEHR persistence solution

Dear all, I just found there are lots of comments on our recent paper. Thanks for all these comments, I will read them and reply later. @Shinji, Of course the slides could be shared. Regards Xudong 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI : > Hi Ian and all, > > We,

Re: Archetype relational mapping - a practical openEHR persistence solution

p://twitter.com/ppazos> > > ---------- > Date: Mon, 25 Jan 2016 18:42:01 +0100 > Subject: Re: Archetype relational mapping - a practical openEHR > persistence solution > From: bert.verh...@rosa.nl > To: openehr-technical@lists.openehr.org > > > Another p

Re: Archetype relational mapping - a practical openEHR persistence solution

Hi Seref, We tested with lots of queries, not with large datasets (tens of thousands) within the system itself. But given the nature of the "normal" relational DB schema and queries, this should be no problem at all. It's good old postgres..:-). Jan-Marc Op di 26 jan. 2016 om 10:53 schreef

Re: Archetype relational mapping - a practical openEHR persistence solution

Hi Thomas, Your solution sounds interesting (looks like postgres hstore). But we are (very) happy with our current stack, so we will not test it. Jan-Marc Op di 26 jan. 2016 om 12:40 schreef Thomas Beale : > > I have not performance tested my own implementation

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26/01/2016 09:51, Bert Verhees wrote: On 26-01-16 10:38, Jan-Marc Verlinden wrote: # Our first version was Java based with a postgres DB, everything stored as path/values. Every query would take about a second. We did not even try complex queries..:-). Also the GUI side did not know what

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 11:25, Jan-Marc Verlinden wrote: Oracle rdbms is indeed ACID. You have to convert the archetype (ADL or XML) to XSD, that will be used to store the XML in a relational DB (for better performance). One small correction, Jan-Marc, this is not possible. Not all constraints possible

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 11:35, Thomas Beale wrote: 50,000 such 'paths of interest'. That's a very small number. These paths can be mapped in smart ways to a 64-but number space so that finding out if a specific query term is in some EHR is very quick. When you include a coded list of archetype ids in the

Re: Archetype relational mapping - a practical openEHR persistence solution

Dear all, I just found there are lots of comments on our recent paper. Thanks for all these comments, I will read them and reply later. @Shinji, Of course the slides could be shared. Regards Xudong 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI : > Hi Ian and all, > > We,

Re: Archetype relational mapping - a practical openEHR persistence solution

This is correct. The usual way I do this with an object model is to create a set of P_XXX classes, where 'P_' means 'persistent form'. The P_ classes are a transform of the main IM (whatever it is) that does things like * stringifying a lot of low-level fields * ignoring derived fields *

RE: Archetype relational mapping - a practical openEHR persistence solution

le=009  Regards Mikael   From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Birger Haarbrandt Sent: den 25 januari 2016 22:57 To: Bert Verhees; For openEHR technical discussions Subject: Re: Archetype relational m

RE: Archetype relational mapping - a practical openEHR persistence solution

Not sure if you ask me Birger, but I will announce the github link here, and will build a working prototype in open source. Maybe parallel I will do something else, I am not sure about that Bert Op 26 jan. 2016 17:26 schreef "Birger Haarbrandt" : > > Thanks! Would be

Re: RE: Archetype relational mapping - a practical openEHR persistence solution

etreff: RE: Archetype relational mapping - a practical openEHR persistence solution Not sure if you ask me Birger, but I will announce the github link here, and will build a working prototype in open source. Maybe parallel I will do something else, I am not sure about that Bert Op 26 jan. 2016

Re: Archetype relational mapping - a practical openEHR persistence solution

ablo 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: bert.verh...@ros

Re: Archetype relational mapping - a practical openEHR persistence solution

Thanks, pazospablo. Yes, you are right. There may generate sparse tables. We found the problem when we using it in the implementation. Currently, we update our method to use "storage template" to specialise the archetypes. The "storage template" will be generated automatically through combining

Re: Archetype relational mapping - a practical openEHR persistence solution

I believe your paper is about performance of an openEHR based system with a relational database. It does not argues if this is the right approach. And specifically on the performance we could not agree more...:-). In the past year we worked on three different versions, all completely openEHR

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 10:38, Jan-Marc Verlinden wrote: # Our first version was Java based with a postgres DB, everything stored as path/values. Every query would take about a second. We did not even try complex queries..:-). Also the GUI side did not know what to do with the pathvalues. Hi Jan-Marc,

Re: Archetype relational mapping - a practical openEHR persistence solution

Interesting discussion..:-). Concerns for our current architecture: - Should be completely according openEHR IM - Accessible for external developers (front-end) through an API. - KISS; hide all openEHR complexity for GUI developers. So no pathvalues output, just simple GET and PUT.

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

based on a quick look, my reaction is the same, unless they have some very interesting Archetype => Schema transformation. On 25/01/2016 14:25, pazospa...@hotmail.com wrote: I talked about this approach with a colleague from China during MEDINFO. The problem is your schema grows with your

Re: Archetype relational mapping - a practical openEHR persistence solution

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

Re: Archetype relational mapping - a practical openEHR persistence solution

Alas, the hyperlink seems to be broken. 25.01.2016, 16:06, "Ian McNicoll" :Interesting paper from China -- Regards, Dmitry ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: Archetype relational mapping - a practical openEHR persistence solution

Actually, we use such mappings to promote some "important" elements to relational tables to get sort of indices on the data. Otherwise, I don't think we would be able to do efficient ad-hoc cross-patient queries directly on the database. Exporting data to I2B2 or SSAS would be inconvenient

RE: Archetype relational mapping - a practical openEHR persistence solution

] On Behalf Of Birger Haarbrandt Sent: den 25 januari 2016 22:57 To: Bert Verhees; For openEHR technical discussions Subject: Re: Archetype relational mapping - a practical openEHR persistence solution Actually, we use such mappings to promote some "important" elements to relational tab

RE: Archetype relational mapping - a practical openEHR persistence solution

with the openEHR model but more "relational friendly". -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com Date: Mon, 25 Jan 2016 18:42:01 +0100 Subject: Re: Archetype relational mapping - a practical openEHR persistence solution From: bert.verh...@rosa.nl To: openehr

Re: Archetype relational mapping - a practical openEHR persistence solution

Hi Ian and all, We, openEHR Japan had an unconference with Dr Lu and he gave us a presentation for us about this research. I will ask him if the slides would be shareble. Shinji KOBAYASHI 2016-01-25 22:04 GMT+09:00 Ian McNicoll : > Interesting paper from China > > >