On 02/04/14 17:33, Birger Haarbrandt wrote: Hi Birger,
> Erik's approach > was to develop a proprietary XML Schema to wrap compositions and > contained entries. Obviously, this might work in a native XML database > like eXist but does not serve our needs. Could you tell more about why a XML database does not serve your needs? > Additionally, storing the > archetypes in a relational fashion is not be our first choice. Why not? > Therefore, I'm interested to learn if any of you has already spent some > thoughts about best practices to split compositions into individual XML > documents while keeping the relationship throughout different tables > and/or rows. I just released information about our "archetyped" MEDrecord. Our goal was to create a more friendly API for MEDrecord based on archetypes. While developing this API it proved to be a small step to also generate SQL schemas from the archetype so that is what we tried. Now we have a version of MEDrecord which stores data in a XML database and a version which stores data in an SQL database whose schema is generated using archetypes. More information about the generated API and schemas can be found here: http://www.medrecord.nl/medrecord-json-api/ We are planning to implement some use cases and then see which approach (XML database or SQL database) works best. But like I said, the main goal of the "archetyped" MEDrecord was to provide a clean, type safe API to clients and not something which can store anything without generating some code first. In time the "archetyped" MEDrecord might grow into such a solution, but currently, for our use cases this is not important. The important aspect is that we can create a clean API quickly which is based on archetypes. What works best, relational database, native XML database or a combination (like PostgreSQL with its XML datatype) is something we still have to figure out. Although I see the benefits of using a native XML database, I do not believe it will have decent performance any time soon on cheap hard- and software for the type of queries we need for building user interfaces without adding many more complexities. Also, we basically treat archetypes as the schema for the information so putting a schemaless database beneath it seems to be a bit of a mismatch. Instead we attempt to convert the schema provided by archetypes into a schema suitable for relational databases and I must say I am quite pleased with the lack of complexity on the server side. The server code turned out to be quite straight forward and simple. Even the complexity of the generator which converts the schemas is manageable. Of course there is room for improvement and maybe it is not enough to implement all possibilities of OpenEHR but for now it is enough to implement the use cases we have in the foreseeable future. We plan to develop it as new use cases present themselves instead of trying to build something which can do anything first and then see if we can fit the use cases in there. Regards, Ralph van Etten MEDvision360 -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
