The data model we use has nothing to do with a database representation. (That is the beauty
of the COAS model). We use a Object Relational mapping layer (inspired by Ambler's work) to
map to a relational or object database. This separation of responsibilities makes the code
more flexible and adaptable.
In addition, we use what some call a EAV style of schema. This really is simply tagged
data equivalent to an XML data structure. That is all of our data in our database is tagged
with the type of data. This gives us enormous flexibility as we can store any type of data
coming in without modifying our database schema one iota. We were not inspired by the
EAV work but really worked with our prior experience and the experience of designing
the COAS specification with a number of vendors. A number of significant ideas in the
specification were provided by 3M from their early and very powerful clinical software.
We don't like to commit to a particular database solution, because each has its own
advantages and proponents. One database may work quite well in a small office
situation, while another may be required in a large hospital setting. Our software
is happy in either situation and requires no recoding to make this transition. In addition,
we have found in many cases the pure object database is probably an order of magnitude
faster than the relational database because of the implicit joins that occur.
As an aside, I would guess that the MUMPS systems are more in this style as it
implements an associative style memory with tagged data. I suspect OpenEMed
would run quite nicely (and transparently) on top of MUMPS, but we've had no time
to check this out.
Dave
At 08:52 PM 12/21/2003, Tim Churches wrote:
On Mon, 2003-12-22 at 14:21, Horst Herb wrote:
> On Mon, 22 Dec 2003 13:58, Tim Churches wrote:
> > Sure, such translators can be used to "roll the data forward" as I
> > describe it above. The issue for us is how to create such translators
> > automatically, or at least how to automate as much as possible of the
> > decision making involved, and ask the end user as few questions as it is
> > safe, without risking inadvertent data loss.
>
> Using PostgreSQL, it is pretty much straightforward using table inheritance.
>
> First version: attributes A,B,C
> Second version (inherits First, adds one attribute): attributes A,B,C,D
> Third version (branched from first) : attributes A,B,C,E,F
> If you want to hide B in the second version, you would generally add an
> attribute of type array "visible" or "in_use" where you can switch
> selectively attributes on and off if you want to create forms on the fly
> fromany given table structure.
>
> That way, any query can easily select from any permutation of ancestors/
> children, ad you still can model your forms from table structures and
> viceversa as you please
>
> Am I thinking too simplicistic or would that actually solve a problem? Of
> course, this would be non-portable, limited to work in Postgres alone.
Yes, that just about solves the problem - certainly no show-stoppers. We briefly considered these object-oriented features of PostgreSQL when we started, but decided to try to strive for back-end independence, and thus put them to one side. However, 7 months later we have a lot more experience with PostgreSQL and now feel quite comfortable about committing to a PostgreSQL-only solution. I think that is the way forward, and thanks for reminding us what a wonderful piece of work PostgreSQL is (aside: pity that MySQL gets all the press coverage).
--
Tim C
PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
