Down the road would be nice to write a paper about a persistence model for openEHR, or at least a ITS for specific DBMS, my focus would be an ITS for relational DBMSs in general, and a second step would be for specific brands, considering specific features of Postgres, MySQL, Oracle, SQLServer, etc. Maybe a good paper topic for the next MEDINFO?
-- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com Subject: Re: Archetype relational mapping - a practical openEHR persistence solution To: openehr-technical@lists.openehr.org From: thomas.be...@openehr.org Date: Tue, 26 Jan 2016 08:49:08 +0000 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 occasionally using a blob transform where it makes sense. Then one can start to consider tools like hibernate on the P_ model. Both the openEHR BMM files and JSON/XML/ODIN save format use this approach. - thomas On 26/01/2016 01: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 _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
