Ian, An object database would be the straightforward answer to persistence since the dabase schema is essentially the class model of your application.
We have used Matisse (www.matisse.com) which is a very solid database engine that doesn't get in the way of your application logic. It has bindings for C++, Java, and dotNET as well as Eiffle (Tom Beale has an excellent open source library Ostore). Matisse has a very small footprint and almost no admininstratio costs - in a case that I am familiar with it has been running for 6 years without any DBA support! If you are interested in other developments, you may want to take a look at db4o (www.db4o.com) which is a small DLL for Java or .NET that you provide a reference to and then use from within your application. It is still evolving but has an increasing number of users around the world. Kind regards, Ogi Pishev Ocean Informatics ----- Original Message ----- From: "Ian McNicoll MMS" <[email protected]> To: <openehr-technical at openehr.org> Sent: Friday, January 20, 2006 3:19 AM Subject: Re: Pesistence Issues was: difficulties starting an implementation > Hi Tim, > >> The research for this thesis directly addresses the issues described >> above. I will be happy to share the thesis and subsequent papers as >> soon as the thesis has been marked (2-3 months?). In short, I would >> suggest that you not let marketing efforts by major >> companies color your perception of how to persist data. > > Point taken? >> If you ask the >> question; "Why do I want to persist data?". Begin with that answer to >> engineer a solution you will (I believe) find an optimal solution. >> > I am very,very intruiged. Any 'sneak peek' of any of your work or ideas > would be very welcome (privately of course if you prefer). > > If I could demonstrate to a skeptical audience that we have a solution > such as OpenEHR to model complex clinical concepts and a way of persisting > it (or not needing to????!!!), I would be a happy chap and my meeting > tomorrow would go a whole lot easier! > > To answer your question 'why do we need to persist data?', I increasingly > feel that we should adopt a document based model of persistence as the > main requirement is speed of access and accessibility to the clinician in > document style. However both clinician and 'secondary data users' have > legitimate though lesser need to analyse and view data in the manner of > bulk SQL queries, for audit, recall purposes etc. My own preference would > be to persist the document 'serially' with embedded hyperlinks to > 'traditional' row-based items. I have not yet got to grips with how this > might be expressed using OpenEHR. > > Rong's comments are interesting. I think he is on the right track by > splitting persistence splitting between normalised tables and serialised > data but correctly identifies that it can be difficult to query such data > effectively. I know that one of the aims of Archetypes is to incorporate > querying capability but I am a little hazy as to how this might work, or > is it simply an XPath/XQuery like mechanism? > > Regards, > Ian >
