Shouldn't heavy weight queries be limited to a separate OLAP platform? This would include most QA/QM and research uses. If you set up the persistence to populate the OLAP as it is saving clinical information to the data repository, you can even have real-time OLAP. I don't know how much of a real difference the RDBMS optimization for a transaction based (i.e. the CDR) and query based (OLAP) make when using a persistence layer like Hibernate.
Kevin Kevin M. Coonan, MD Adjunct Assistant Professor, Division of Emergency Medicine NLM Fellow, Department of Medical Informatics University of Utah School of Medicine Co-chair, HL7 Emergency Care Special Interest Group kevin.coonan at utah.edu -----Original Message----- From: [email protected] [mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, March 08, 2006 4:08 AM To: openehr-technical at openehr.org Subject: Re: persistence layer Tom Tuddenham wrote: > Hi folks > > Standard qualifier for probably not understanding what's going on, but > isn't XML persistence slightly orthogonal to managing Archetypes? I > mean to say, persistence is important but can't it be deferred to a > systems that already offer XML native based persistence, e.g. > http://www.sleepycat.com/products/bdbxml.html or one of the existing > XML-to-RDBMS mapping solutions. > > Again, I may misunderstand what you're trying to achieve, but won't > storing serialized data in the second column make for potentially > complex queries, especially if you're doing keyword searches. I'm > undoubtedly showing my cluelessness here - but wouldn't an XQuery > based interrogation of the repository work be more applicable than SQL? > none of this is clueless, don't worry. In fact you have hit several nails on the head. I am in the middle of writing an FAQ on all this still which I will try and get up in the next few days. In summary: * persisting openEHR data structures e.g. Compositions etc is no different from persisting any other typically fine-grained hierarchical / object data * so you can do normal analysis on it; you can store serilialised data blobs, and queries do then have to be thought about more carefully; but the other side of the coin is that not every fine-grained node needs tobe directly queryable.... * except for one little exception - due to being archetyped, the data is full of node ids and hence every node is guaranteed to be addressable with an Xpath-style path (we do a couple of machine-processable shortcuts on our paths to reduce the length, but otherwise they are Xpaths - see the section on Paths in http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview. pdf. So one very interesting option for storing the data is as <path, serialised node> pairs, which is dead easy in a relational database, and is very queryable, due to the paths being semantically meaningful (due to being defined by archetypes). What I aim to do is to just put up an initial FAQ; there is no doubt a lot of expertise in object and O/R persistence here in the community, and I would like to get others to contribute their knowledge as well (without trying to write just a general purpose lesson on O/R persistence - there are many of those already available). (Probably we should set up a wiki at some point....) - thomas
