Scott,

I only briefly perused the subsequent exchange, but if you make a solid
decision on the entities being database and then a solid table structure
based on that, then I think you job will be much easier / more successful.

The first question is whether "dates" are an entity that needs databasing
vs. just an attribute of other entities.

If the answer is yes, the next question is whether or not your "date"
entity has other 1:1 attributes that you will be actively databasing. That
will make the difference between a true data table vs. a table that is just
there to populate dropdown lists.

Either way, I suspect that you will need to ditch a few of your tables and
your main 3 tables should be:

People

Functions

InstancesOfAPersonServingAFunctionOnAParticulerDat e (of course, shorten
that). This table will have FK's for People and Function and probalby just a
date field, but possible a FK for a dates table, if the latter is truly an
entity that needs databasing.

Well, there's my 2 cents.




Even if the answer is the former, then the next question is whether or not
you need to