Question

I have a table that will contain information for 3 other tables. The design I have is that this table will have a column that will tell the objects’s ID and another column will tell the objects’s type (and thus the table that that row refers to).

Two questions:

a) Is that the best design or is there something else more widely accepted?

b) What is the recommend procedure to assure that IDs are valid for the given objects’s type?

Answer 1

If I understood your question correctly, each row in your table links to exactly one of the three other tables.

Your approach (type field + one foreign key field) is a valid design, and it’s useful if you want to create a general-purpose table that contains meta-information about your data (e.g. a list of records that should be retransmitted for replication).

Another approach, which might be more suitable for real application-level data, would be to have three columns, each being a foreign key to one of the three tables, and to add a constraint that requires exactly two of those fields to be null. The has the following advantages:

• The three FKs do not need to have the same data type.
• The JOIN syntax becomes more natural (not involving the type field).
• You can add referential integrity constraints on those FK columns.
• You don’t need to ensure correctness of the type field — in fact, you don’t need the type field at all. The type is determined implicitly by the one FK column which is not null.