Comments below
On 8/6/05, Kennedy, Jim <jim_kennedy@xxxxxxxxxx> wrote:
>
>
>
> I explain NULLS in the following manner.
>
> Imagine a medical application where your medical data is stored in a
> database. Imagine that your Dr. has never asked you if you have
> allergies or not. Further imagine that you become unconcouse and go to
> the emergency room. The Dr. in the emergency room looks at your
> electronic medical data. Given the information in your electronic chart
> what should the Dr. assume about your allergic reactions?:
> A. You are Alergic to something.
> B. You are not allergic to anything.
> C. It is unknown if you are or are not allergic to anything.
>
> The Dr. should assume C. You have not been asked the question so the
> data in that column is NULL and the Dr. should make NO assumptions about
> your medical condition visa vis allergys. In medicine even if they
> asked you the question "Are you allergic to anything?" and you answered
> "No" the correct value to store is NKA - No Known Allergies. After
> this explanation most people understand what a NULL is.
> Jim
Isn't this a great example of how a better design is a better solution?
Wouldn't
PATIENT
=======
PATIENT_PK
....................
ALLERGEN
=========
ALLERGEN_PK
........................
KNOWN_ALLERGIES
================
PATIENT_PK -- foreign key
ALLERGEN_PK -- foreign key
IDENTIFIED_DATE
.....
Be a better design? Then the doctor would just pull up a list of known
allergies (which might of course be empty). This is a lot different, and I'd
argue better, than pulling up a NKA or NULL value.
--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com