Can Foreign Key be null? [duplicate]

The column (or columns) of a primary key must be NOT NULL. A record cannot be uniquely identified by a NULL. So the ID columns on the referenced end of the foreign key must be defined as NOT NULL.

However, it is a legitimate design decision for a foreign key relationship to be optional, and the way to represent that is by making the referencing end of the key optional, i.e. allowing NULLs.

In data modelling terms what you have described is an (exclusive) arc: "a table ... with two or more foreign keys where one and only one of them can be non-null." In logical modelling arcs are perfectly acceptable, but there is a strong body of opinion in favour of implementing them as separate tables. In your scenario that would be a generic Sale table plus two sub-type tables, VehicleSale and PieceSale.

The advantages of the separate table implementation are:

• easier to enforce the foreign key constraints;
• easier to add additional columns relating to (say) vehicle sales which don't apply to piece sales;
• easier to extend the model with additional sub-types;
• clearer data model, which can simplify application development.

However, the advantages aren't all one-way. While it is pretty easy to ensure that a Sale applies either to a VehicleSale or a PieceSale but not both, enforcing a rule that a Sale must have a child record actually gets pretty gnarly.

So, the prevailing advice is that an exclusive arc is mistaken, and it is generally good advice. But it's not as clear as some make out.

Answer:

Yes, you can do that - make the FKs themselves NULL-able, but add a CHECK to ensure exactly one of them contains a non-NULL value.

Elaboration:

A FK can be NULL-able, which models a 1..0:N relationship. In other words, a "child" row can (but is not required to) have a "parent" row.

A NOT NULL foreign key models a 1:N relationship. In other words, every child must have a parent.

When a FK is composite¹, and at least one of its fields is NULL-able, a mix of NULL and non-NULL values is handled in a special way:

• If the FK is MATCH FULL, either all values must be NULL or all values must be non-NULL and match some parent row.
• If the FK is MATCH PARTIAL, only those values that are non-NULL must match some parent row (NULLs are ignored).
• If the FK is MATCH SIMPLE, either all values are non-NULL and must match some parent row, or there is at least one NULL value (in which case the non-NULLs are not required to match).

Most DBMSes default to MATCH SIMPLE (with the notable exception of MS Access) and most don't support anything but the default.

¹ Which you don't have here - just mentioning it for completeness.

Depending on what you mean by "exclusive foreign keys", you might be thinking of vehicles and pieces as two subclasses of some larger superclass, call it saleable items.

If you use a design pattern called "class table inheritance", you will have three tables, one for the superclass, and one for each subclass table. If in addition, you use a design called "shared primary key", you can use the same primary key for all three tables.

This would enable your Sale table to have a single foreign key, Saleable_Item_Id, that references the Saleable_Item table and also either the Vehicle or the Piece table, depending on the case. This could work out better for you than the existing design.

google "class table inheritance" and "shared primary key" for more details.