[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 (
    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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]