[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: Info and to-do tracking schema
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] Re: Info and to-do tracking schema |
Date: |
Sat, 2 Oct 2004 09:23:53 -0700 |
At 11:34 AM +0200 10/1/04, Karsten Hilbert
wrote:
The simplest thing I
can imagine is that there is a todo
table that has these fields:
create table clinical_todo (
pk,
fk_type,
comment text,
context_link integer
) inherits (audit_fields, clin_root_item);
A generic enter-clinical-todo widget would have the user pick a
type (eg. refill request) and have him enter some info, eg.
"Pharmacy Wilson at K-Mart called for refill on
sildenafil".
Such requests would always relate to a given patient (defined
via clin_root_item). The context_link field would serve
to
store a non-checked
foreign key to a clinical table, say, a
^^^^^^^^^^^^^^^^^^^^^
previous
prescription. The widget needs to know what to put
there depending on fk_type. It might also be kept as
NULL.
This can wait 'til you are back from "training"
;-)
How is a "non-checked" foreign key different from other
(default "checked"?) foreign keys? Is it a matter of storing
the "value" of what would be the foreign key, without
defining or requiring the field to be treated "as" a foreign
key, in case for some reason it is desirable to modify table content
independently?
If a foreign key that is "non-checked" does not
function truly or properly *as* a foreign key, should we name it
something other than fk_? like ncfk_ or ek_ for external key?