> Rong, > > >We use "table per class hierarchy" strategy to map inheritance. For > the >ItemStructure attribute of Party, just declare a "many-to-one" > and >hibernate will take care of the rest ;) > > Does that mean you use a single table to map the data value class > hierarchy? If so how do you handle generics? Do you also have > different columns for each of instance of the generic type? > > Do you use eager loading through Hibernate or lazy loading? > > Do you have any indication on performance using this approach? > >cheers ></jima> >
Hi, I believe that the correct design approach to all this is not to try to persist instances of the openEHR classes directly, but to have another set of simplified classes which are designed to remove most of the fine-grained hierarchical nature of the data structures - which is the thing that most affects performance in both relational and even somewhat in object databases. The obvious candidate for s simplified class is ENTRY and its subtypes; a persistent version of such classes should convert all of the fine-grained object information into Strings and other basic types which are fast on all kinds of databases. This is a reasonable thing to do, because querying the interior fine-grained items in an ITEM_LIST or ITEM_TREE for example won't make much sense - and is dangerous. You hvae to get the whole path to get the correct meaning of such structures in openEHR, else you risk mistaking "hip replacement" (planned) for "hip replacement" (done last august) or "hip replacement" (not recommended for 3 months) and so on. A relatively small number of classes could be used (named appropriately, e.g. OBSERVATION -> P_OBSERVATION meaning 'persistent') to map the entire of the openEHR structures into much simpler objects which map more easily to relational structures, and remove a lot of the hiercharchical complexity. The other advantage of this is that it defines such a mapping - think of it as a mathematical transform - inside the openEHR specifications, and locks it down for everyone to use. We will need some experimentation and experience to get it right, but I would forsee such an approach as being 'standardised' in openEHR by release 1.1 or 1.2. I'll try to publish some early design thoughts on this in a week or so. - thomas beale -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
