I've had excellent success with objectdb (www.objectdb.com), which is a pure Java object database. It is very fast, very small footprint, no administration and inexpensive.
Dave On Thu, January 19, 2006 4:22 pm, Ognian Pishev said: > 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" <ian at gpacc.co.uk> > 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 >> > > > -- David Forslund Laboratory Fellow Associate CCS-DO MS B265 Los Alamos National Laboratory Los Alamos, NM 505-665-2633
