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