Establishing referential integrity in a generic table? Current Schema:

 - DropDown:
     DropDownID PK, 
     Name nvarchar(25)

 - DropDownOption: 
     DropDownOptionID PK, 
     DropDownID FK, 
     Name nvarchar(25), 
     Description nvarchar(155)

 - Estimate: 
     EstimateID PK, 
     JobDifficultyID FK(DropDownOption), 
     JobTypeID FK(DropDownOption), 
     etc.

 - Note there are 5+ Tables With links to DropDownOption similar to Estimate.


How can I establish referential intregity (i.e. JobDifficultyID can only point to DropDownOptions that are apart of JobDifficulty DropDown) without creating separate tables (i.e. Instead of DropDown &amp; DropDownOption having JobDifficultyTypes, JobTypeTypes, etc)

Alternative Schema:

- JobDifficultyType: 
    JobDifficultyTypeID PK, 
    Name nvarchar(25)

- JobTypeType: 
    JobTypeTypeID PK, 
    Name nvarchar(25)

- Estimate: 
    EstimateID PK, 
    JobDifficultyTypeID FK, 
    JobTypeTypeID FK, 
    etc.


This would result in at least 13 new tables. Is this the appropriate way or is there a robust way to combine all the miscellaneous types into a single table while maintaining referential integrity?
You can use this design, which requires one more table:

 - DropDown:
     DropDownID  PK, 
     Name nvarchar(25)

 - DropDownOption: 
     DropDownID  FK (DropDown)  UQ1, 
     DropDownOptionID  PK       UQ1,
     Name nvarchar(25), 
     Description nvarchar(155)

 - Estimate: 
     EstimateID  PK, 
     etc.

 - EstimateOption: 
     EstimateID  PK,   FK1 (Estimate)
     DropDownID  PK    FK2 (DropDownOption), 
     DropDownOptionID  FK2 (DropDownOption)


For every row in Estimate, you'll have to add (up to) 13 rows in the EstimateOption table (one for each dropdown menu).

The additional Unique constraint in the DropDownOption table is needed for the foreign key (FK2) from the EstimateOption table.

What you have in your current design as Estimate, can then be constructed with a pivot query from the two tables.