Question

I realize in many cases, putting “None” might not seem so bad. However, I want to use the values in this particular lookup table (several thousand rows) in a different table which contains several non-nullable fields that relate directly to the data which comes from the lookup table.

Real-World Scenario:

The lookup table is a list of generic drug names, and contains codes for joining on other databases separate from our application.

We have a prescription table which stores DrugId, OrderId (FK), frequency, dosage, etc., all which are presently non-nullable.

In certain scenarios, prescription information for an order is required, so solving the problem simply by not having a record (and no other means of tracking,) will not suffice–we need to be able to know why there are no prescriptions entered and be able to re-populate the correct reason when reviewing the data at a later date.

One idea is to add “None” as part of the Drug lookup table, which forms the basis for this question. I worry about taking this approach for several reasons:

• it seems like in every scenario when we want to consume the data, we much remember to account for this (with a couple minor exceptions, since as inner-joining on a 3rd party database.)
• This seems very non-obvious for anybody coming onto the project, (not to mention a pain in the butt,) and must be tested for uniquely. Maybe doing this with “None” alone isn’t so bad, but what about it we wanted to add “Declined” or “Don’t Know” into the mix? Now there are 3 non-obvious exceptions sitting in our look-up table which must be accounted for EVERY SINGLE TIME the data is accessed.
• Either we make the currently required fields nullable or insert bogus data into them.

Other ideas to address this scenario are:

• add a new column to the order with options such as “has prescriptions,” “declined,” “no prescriptions.” This isn’t desired since tens of thousands of rows will be ‘null,’ but otherwise doesn’t seem too bad.

• make a new table to log only the ‘exceptional’ cases, such as “none” or “don’t know” for when the field is required. This is, at the moment, the one which appeals to me the most, since it creates very obvious exceptional cases which must be accounted for. The downside, of course, is a new table (one-zero relationship,) with a very small number of columns. This seems like it would be the simplest form of data to consume for re-population of the UI.

Thoughts of the SO community?

Answer 1

You could add two fields to order

LookupValueID NULL FK,
PrescriptionType tinyint

With PrescriptionType = (Present = 1, Null = 2, Declined = 3, DontKnow = 4, ...)

And add a CHECK constraint:

(PrescriptionType = 1 AND LookupValueID IS NOT NULL)
OR (PrescriptionType <> 1 AND LookupValueID IS NULL)

That way, you inline a constant number of common special cases into the main table (Orders I think) and enforce data correctness using a constraint.