Re: [Gnumed-devel] Re: Info and to-do tracking schema

[J Busser]

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?