La colonna (o le colonne) di una chiave primaria deve essere NOT NULL. Un record non può essere identificato in modo univoco da un NULL. Quindi le colonne ID all'estremità di riferimento della chiave esterna devono essere definite come NOT NULL.
Tuttavia, è una decisione di progettazione legittima che una relazione di chiave esterna sia facoltativa e il modo per rappresentarla è rendere opzionale l'estremità di riferimento della chiave, ovvero consentendo NULL.
In termini di modellazione dei dati, ciò che hai descritto è un arco (esclusivo):"una tabella ... con due o più chiavi esterne in cui una e solo una di esse può essere non nulla". Nella modellazione logica gli archi sono perfettamente accettabili, ma c'è un forte corpo di opinioni a favore della loro implementazione come tabelle separate. Nel tuo scenario sarebbe una Sale generica tabella più due tabelle di sottotipo, VehicleSale e PieceSale .
I vantaggi dell'implementazione di tabelle separate sono:
- più facile applicare i vincoli della chiave esterna;
- più facile aggiungere colonne aggiuntive relative a (diciamo) vendite di veicoli che non si applicano alle vendite a pezzi;
- più facile estendere il modello con sottotipi aggiuntivi;
- modello di dati più chiaro, che può semplificare lo sviluppo delle applicazioni.
Tuttavia, i vantaggi non sono tutti a senso unico. Anche se è abbastanza facile garantire che una Sale si applica a un VehicleSale o un PieceSale ma non entrambi, applicando una regola che è una Sale deve avere un record figlio in realtà diventa piuttosto nodoso.
Quindi, il consiglio prevalente è che un arco esclusivo è sbagliato, ed è generalmente un buon consiglio. Ma non è così chiaro come alcuni credono.
