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 <http://cabolabs.com/es/home>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
