Kolumnen (eller kolumnerna) för en primärnyckel måste vara INTE NULL. En post kan inte identifieras unikt med en NULL. Så ID-kolumnerna på den refererade änden av den främmande nyckeln måste definieras som NOT NULL.
Det är dock ett legitimt designbeslut att en främmande nyckelrelation är valfri, och sättet att representera det är genom att göra referensänden på nyckeln valfri, d.v.s. tillåta NULL.
I termer av datamodellering är det du har beskrivit en (exklusiv) båge:"en tabell ... med två eller flera främmande nycklar där en och endast en av dem kan vara icke-null." I logisk modellering är bågar helt acceptabla, men det finns en stark opinion för att implementera dem som separata tabeller. I ditt scenario skulle det vara en generisk Sale tabell plus två undertypstabeller, VehicleSale och PieceSale .
Fördelarna med den separata tabellimplementeringen är:
- lättare att upprätthålla begränsningarna för främmande nyckel;
- lättare att lägga till ytterligare kolumner relaterade till (säg) fordonsförsäljning som inte gäller styckeförsäljning;
- lättare att utöka modellen med ytterligare undertyper;
- tydligare datamodell, som kan förenkla applikationsutveckling.
Men fördelarna är inte alla enkelriktade. Även om det är ganska enkelt att se till att en Sale gäller antingen en VehicleSale eller en PieceSale men inte båda, genom att upprätthålla en regel som en Sale måste har ett barnregister blir faktiskt ganska knotigt.
Så det rådande rådet är att en exklusiv båge är felaktig, och det är generellt sett ett bra råd. Men det är inte så tydligt som vissa tror.