There's another option: not one I'd fully endorse, but it's still another option:
Use three tables:
refs (id, title, refType)
-- title of the reference, and what type of reference it is
fieldDef (id, fieldName, refType, dataType)
-- name of the field, which reference types it applies to, and
-- what type of data is stored in these fields (ISDN number, date, etc)
fields (refId, fieldId, value)
-- where you actually add data to the references.
refType can be the type of reference, and if you make it an integer with values increase by powers of two (1, 2, 4, 8...) then they can be added together to make a bitmask in the fieldDef table.
Pros: very simple and extensible. If you come up with another type of reference, or a new field type for an existing reference type, it can be added in very quickly. Forms can be automatically generated for each reference type. All data is stored in one place, meaning you don't need to keep track of multiple schemas (schemata?) for CRUD operations.
Cons: this is the stuff that The Daily WTF is made on. Select statements can become very confusing and complicated. The database can't perform type-checking (eg: for dates, etc), and the generic "value" field will not be optimised for the data being stored in it.
