De kolom (of kolommen) van een primaire sleutel mag NIET NULL zijn. Een record kan niet uniek worden geïdentificeerd door een NULL. Dus de ID-kolommen aan het uiteinde van de refererende sleutel waarnaar wordt verwezen, moeten worden gedefinieerd als NOT NULL.
Het is echter een legitieme ontwerpbeslissing dat een externe sleutelrelatie optioneel is, en de manier om dat weer te geven is door het verwijzende einde van de sleutel optioneel te maken, d.w.z. NULL's toestaan.
In termen van gegevensmodellering is wat u hebt beschreven een (exclusieve) boog:"een tabel ... met twee of meer externe sleutels waarvan één en slechts één niet-null kan zijn." In logische modellering zijn bogen volkomen acceptabel, maar er is een sterke mening voor het implementeren ervan als afzonderlijke tabellen. In jouw scenario zou dat een generieke Sale . zijn tabel plus twee subtype tabellen, VehicleSale en PieceSale .
De voordelen van de afzonderlijke tabelimplementatie zijn:
- gemakkelijker om de externe sleutelbeperkingen af te dwingen;
- gemakkelijker om extra kolommen toe te voegen met betrekking tot (bijvoorbeeld) voertuigverkopen die niet van toepassing zijn op stukverkopen;
- gemakkelijker om het model uit te breiden met extra subtypes;
- duidelijker gegevensmodel, dat de ontwikkeling van applicaties kan vereenvoudigen.
De voordelen zijn echter niet allemaal eenrichtingsverkeer. Hoewel het vrij eenvoudig is om ervoor te zorgen dat een Sale is van toepassing op een VehicleSale of een PieceSale maar niet beide, een regel afdwingen dat een Sale moet een kinderrecord hebben wordt eigenlijk behoorlijk lastig.
Het heersende advies is dus dat een exclusieve boog verkeerd is, en het is over het algemeen een goed advies. Maar het is niet zo duidelijk als sommigen beweren.