Where should I store a foreign key?

Question

If I have a relationship between two tables (both tables have their own primary keys) what should guide my decision as to which table should store the foreign key? I understand

Answer 1

Which table is the child in the relationship?
Answer that, and you know which table needs the foreign key column, referencing the parent's [typically] primary key. That's for a one-to-many relationship...

A many-to-many would require you to add a third table, using the keys from both of the two tables as it's primary key.

Answer 2

A foreign key is simply a field in one table that refers to a key field of another table. It's not absolutely critical to identify the foreign key field as such. That is, you don't need to explicitly add the FOREIGN KEY ... REFERENCES constraint to the table for it to be a foreign key. When you join the two tables together, the primary key of the parent table will be set equal to the foreign key of the child table. Whichever one is not the primary key is the foreign key.

In one-to-many relationships, the FK goes on the "many" side. It can't go on the "one" side because that's where the PK goes and the definition of a primary key includes disallowing duplicates.

If you have a many-to-many relationship, you'll need to re-work the tables so you end up with two one-to-many relationships and an intermediate resolution table.

Answer 3

Like a primary key, a foreign key is also a type of constraint placed on one or more columns in a table.

The foreign key establishes a link between the key columns and related columns in another table. (You can also link the foreign key columns to columns within the same table.)

The table that contains the foreign key is considered the child table, and the table that the foreign key references is the parent table.

Key Points

1. The foreign key must reference a primary key or unique constraint, although that reference can be on the same table or on a different table
2. A foreign key must also have the same number of columns as the number of columns in the referenced constraint, and the data types must match between corresponding columns.
3. Unlike Primary key, Foreign key columns can contain NULL values.

Answer 4

"What is a systematic way of making that decision though?"

There appear to be two choices: The "One" side as FK's to the "Many side", or the "Many" Side has FK's to the "One" side.

Let's actually look a the choices.

• All the rows of the "Many" side can easily reference one row on the "One" side.

• The one row on the "One" side cannot ever reference ALL of the rows on the "Many" side.

Only one technique works: "Many" side has FK to "One" side.

There is only one actual implementation choice. There's no "decision".