> > Here's a real live schema using (mostly) the above approach:
> >
> > http://www.gnumed.de/~ncq/gnumed/schema/gnumed_v20/
> >
> > in case anyone is interested in taking a look.
> >
> > Karsten
>
> Apparently (according to your naming convention) several tables (such as
> 'clin.substance_intake') have 2 PRIMARY KEYs!!!
You've picked perhaps the most complex table in there :-)
> Can you tell us more about the database (ignoring nit-picking!)?
Sure. All the clinical tables inherit from clin.clin_root_item
which itself has a primary key (pk_item) and which, in turn,
inherits from audit.audit_fields, which, again, has a primary
key of its own (pk_audit). That is what makes several tables
appear to have more than one primary key. However, only the
top level serial column is declaratively set to be the actual
primary key of any one table. Certainly, hose columns all _do_
have the properties of primary keys.
Inheritance from clin.clin_root_item is leveraged for cross-table
search of clinical narrative, for one thing.
That table is also overly complex as it needs to take account
of patients being documented to be on treatment regimes with
a mixture of either branded drugs, possibly containing several
active substances, and generic substances without a documented
brand. That's why it is overly complex (I haven't found a
better way to implement this requirement).
Anything else you'd like to know ?
Karsten
