Consentire null a una chiave esterna

• Quando modellate concettualmente, le relazioni che sono obbligatorie su entrambe le estremità sono possibili, ma nel mondo fisico delle tabelle non esistono, perché impedirebbero le inserzioni, poiché non è possibile inserire A senza una B corrispondente e viceversa. Quindi nel RDBMS uno dei fini della relazione deve essere non obbligatorio, cioè consentire null.
• IMO il rapporto tra VehiclePlants e VehicleModels deve essere M: M, il che significa che deve essere creata una tabella di join con chiavi esterne che puntano a entrambe le tabelle. Ovviamente, entrambi gli FK devono essere obbligatori.
• L'assenza di una relazione tra una data riga in VehiclePlants e una data riga in VehicleModels è data dall'assenza di una riga nella tabella di join, non da alcun valore nullo.

Il mio consiglio è questo:

• In un primo momento, per rendere felice il cliente, modella come se la relazione fosse 1: M ma crea il PK della tabella di join in modo che sia una relazione di fatto 1: 1 nonostante la tabella di join :

TienipresentechepoichéilPKèsolol'FKchepuntaaVehiclePlants,consentiràsolounarigaperVehiclePlantsrendendolaunarelazionedifatto1:1.

• DopocheilclientesirendecontochelarelazioneèinrealtàM:M,operchéparlidisentirloinlui/lei,orealizzandocheunarelazione1:1èimpossibileperchécisonogiàdatiM:Mnelletabelle,quindicambiadePKperconsentireM:M:

SinoticheorailPKèilcompostodientrambigliFK,creandolarelazioneM:M.Ovviamente,comeognirelazioneM:M,èopzionalenelRDBMSphusycal,ilchesignificacheèpossibileinserireinVehiclePlantseinVehicleModelssenzaunarigacorrispondentenellatabelladijoin

Inoltre:

Consideral'aggiuntadiunadimensionetemporaleadesso.

IMHO invita il cliente a ripensarlo prima che sia troppo tardi. Una fabbrica di veicoli potrebbe assemblare più di un modello e un modello potrebbe essere assemblato in più di un impianto. E questo non tocca nemmeno la superficie di dove le parti potrebbero essere prodotte.

Senza più contesto, l'unica opzione ragionevole a lungo termine sembra essere una relazione n-n tra i modelli e le tabelle delle piante. Lo modellerai con una specie di tabella model2plant con una tupla ID che funge da chiave primaria, in questo caso null fondamentalmente non può essere un'opzione.

La tabella correlata n-n potrebbe anche contenere informazioni aggiuntive se pertinenti, ad es. un modello potrebbe essere prodotto in un impianto da una data di inizio a fine, e ancora una volta in seguito, o la capacità di produzione potrebbe variare nel tempo. Per quanto ne sai, potrebbe voler ricostruire le informazioni storiche a un certo punto e vorrai anticiparle nel tuo progetto. Esamina cambiando lentamente le dimensioni mentre ci sei, per ottenere informazioni su come modellare il tipo di cose che lentamente cambia nel tempo.

Se il tuo cliente insiste per avere una relazione 1-1, tieni presente che potresti anche unire le due tabelle e liberarti completamente della tua domanda correlata a nulla mentre ci sei. Ma sottolinea che questo sarà semplicistico e esploderà in faccia nel momento in cui hanno un modello o una pianta che non "si adatta".

Se si tratta di una relazione 0-1 o 1-n / 0-n, che è ciò che la tua domanda sembra implicare, quindi con tutti i mezzi consentire null per motivi pratici, anche se non lo si consente nell'interfaccia oggi: La legge di Murphy si applica qui come sempre - la domanda non è se avrai mai bisogno di inserire un modello il cui impianto di assemblaggio è sconosciuto, ma quando .

Se nella tabella sono presenti righe, è necessario consentire alla colonna di consentire il null. FK può essere nullo.

Dopo aver ottenuto la colonna popolata, dipende da. La pianta sarà sempre conosciuta quando il modello viene creato (inserito)?

Deve essere scelto nell'applicazione , dovrei consentire che sia nullo? Non significa che debba essere applicato nel DB. Gli sviluppatori di applicazioni potrebbero voler inserire un record vuoto. E far rispettare il requisito a livello di applicazione.

Il mio approccio dipenderà solo da una cosa: i modelli senza relazione con una pianta saranno una cosa da qualche parte nel futuro ?? se così fosse, andrei con valori null fino in fondo.

D'altra parte, se non è così, come vedo, invece di consentire valori nulli, mi unirei al tavolo intermedio con i modelli di veicoli quando la relazione è "di fatto" uno a molti, per molti a molti esistenti le relazioni e non si può ottenere alcun aiuto per eliminare le relazioni indesiderate che rimango con la simulazione come modo per identificare i record che devono essere aggiornati.