Kolonnen (eller kolonnerne) i en primærnøgle skal IKKE være NULL. En post kan ikke entydigt identificeres med en NULL. Så ID-kolonnerne i den refererede ende af fremmednøglen skal defineres som IKKE NULL.
Det er dog en legitim designbeslutning, at et fremmednøgleforhold er valgfrit, og måden at repræsentere det på er ved at gøre referenceenden af nøglen valgfri, dvs. tillade NULL'er.
I datamodelleringstermer er det, du har beskrevet, en (eksklusiv) bue:"en tabel ... med to eller flere fremmednøgler, hvor kun én af dem kan være ikke-nul." I logisk modellering er buer helt acceptable, men der er en stærk holdning til fordel for at implementere dem som separate tabeller. I dit scenario ville det være et generisk Sale tabel plus to undertypetabeller, VehicleSale og PieceSale .
Fordelene ved den separate tabelimplementering er:
- lettere at håndhæve begrænsningerne for fremmednøgle;
- lettere at tilføje yderligere kolonner vedrørende (f.eks.) bilsalg, som ikke gælder for styksalg;
- lettere at udvide modellen med yderligere undertyper;
- klarere datamodel, som kan forenkle applikationsudvikling.
Fordelene er dog ikke alle envejs. Selvom det er ret nemt at sikre, at et Sale gælder enten for et VehicleSale eller et PieceSale men ikke begge dele, håndhæver en regel om, at et Sale skal at have en børnejournal bliver faktisk ret knudret.
Så det rådende råd er, at en eksklusiv bue tager fejl, og det er generelt et godt råd. Men det er ikke så tydeligt, som nogle antyder.