>Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D
Aren't several major OpenEHR systems using XML or stored blobs on top of a rather minimal DB schema? The problem with ORM systems would ultimately be a rather bloated schema and hard-wired classes to accommodate that schema. Yes, ORM lets you automate the creation of DB data structures and classes, but, once created, they become part of the schema and your DLLs, which is fine until you have many hundreds of them (tables and classes defined in autogenerated code, etc.). Randy Neall Veriquant, L.L.C. On Thu, Feb 16, 2012 at 5:26 PM, pablo pazos <pazospablo at hotmail.com> wrote: > Hi M?rcio, > > There is no standard persistence model, the persistence mechanism is not > in the standard scope. > > There are many ways of storing openEHR RM instances (archetyped data), the > only thing to take into account is that the information to store will be > highly hierarchical. > > Said that, in EHRGen [1] we use a relational model with an > Object-Relational Mapping [2] tool (GORM from Grails Framework[3]). The > advantage of that is that you have a complete and validated RM instance > persisted on the DB, and you can query for complete objects or single data > ELEMENTS. I've written ORM tools myself [4] and the main problem is the > amount of joins you need to load a complete structure, but in my experience > you never load a complete structure for a real time interaction with the > user, and you alway can cach? some data. > > This approach is straight forward, because all you need are the classes of > the RM, and you delegate DB stuff to the ORM tool. > > Other models are viable too, like K/V [5] or EAV [6] approaches (mentioned > by Bert). This approaches are fast for saving and loading data, the problem > is that you need to have some complex logic above that for constructing a > complete RM instance on memory, because K/V is a flat representation of a > higly hierarchical tree structure. > > Other models I didn't try yet are Object Oriented DBs and Document > Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast > for store highly hierarchical structures, but you need to write some ugly > queries if you want your data back :D > > Hope that helps. > > [1] http://code.google.com/p/open-ehr-gen-framework/ > [2] http://grails.org/ > [3] http://en.wikipedia.org/wiki/Object-relational_mapping > [4] http://code.google.com/p/yupp/ > [5] http://en.wikipedia.org/wiki/NoSQL > [6] > http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos <http://twitter.com/ppazos> > > ------------------------------ > From: mdckoury at gmail.com > Date: Thu, 16 Feb 2012 16:53:19 -0300 > Subject: openEHR - Persistence of Data > To: openehr-technical at openehr.org > > > Hello guys, > > i'm starting a research about the persistence model of Archetype data, > that stores the information entered by the user of the system. > > I would like to know if there is a indication of the openEHR standard for > what kind of model schema should be used in DataBase, and if there are > researchs in this area. > > Thanks in advance, > > *M?rcio Costa* > B.Sc. in Computer Science @ Cin/UFPE > M.Sc. Candidate in Computer Science @ CIn/UFPE > MSN: mdckoury at gmail.com > > > _______________________________________________ openEHR-technical mailing > list openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/54de63ba/attachment.html>
