Svantaggi dell'utilizzo di una chiave esterna nullable invece della creazione di una tabella di intersezione

Supponiamo di avere il seguente diagramma ER:

Ora, se rappresentassi la relazione usando una chiave esterna di Schoolin Student, potrei avere dei NULLvalori (perché a Student non è richiesto di appartenere a a School), ad esempio:

Quindi il modo corretto (basato su ciò che ho letto) è quello di creare una tabella di intersezione per rappresentare la relazione, ad esempio:

In questo modo, nessun NULLvalore può essere presente nella tabella School_has_Student.

Ma quali sono gli svantaggi dell'utilizzo di una chiave esterna nullable invece di creare una tabella di intersezione?

Modificare:

Ho erroneamente scelto ( school_id, student_id) di essere la chiave primaria per la School_has_Studenttabella, che ha reso la relazione molti-a-molti. La chiave primaria corretta avrebbe dovuto essere student_id:

I due modelli rappresentano relazioni diverse.

Utilizzando una tabella di join, si modella una relazione molti-a-molti.

Usando una semplice chiave esterna, stai modellando una relazione uno-a-molti.

Lo svantaggio di una chiave esterna nullable è di non riuscire a modellare la relazione come molti-a-molti, se è quello che stai cercando di realizzare.

In base alla tua modifica alla domanda, stai effettivamente dividendo la tabella degli studenti in due tabelle con la stessa chiave. In genere lo vedo su tavoli che hanno troppi campi, quindi qualcuno li divide in due per essere più gestibili (lo chiamo mettendo il rossetto su un maiale).

Dividendo la tabella degli studenti, si rende facoltativa la seconda tabella poiché nella seconda tabella non è necessario un record. Che è molto simile a un campo che non deve essere impostato perché può essere nullo.

Se si desidera una relazione uno-a-molti, è molto meglio usare una singola tabella e consentire l'ID scuola di essere nullo nella tabella degli studenti. Non c'è motivo di evitare valori nulli nei campi, anche per una chiave esterna. Ciò significa che la relazione estera è facoltativa: gli sviluppatori e i DBA lo capiscono chiaramente e il motore di database sottostante dovrebbe sicuramente funzionare bene.

Se sei preoccupato per le iscrizioni, non preoccuparti. Esistono semantiche ben definite su come funzionano i join con i campi null. Utilizzando una singola tabella, è possibile unire due tabelle anziché tre.

Hai scritto in un commento sopra:

il libro "Fondamenti di sistemi di database" [...] afferma che si consiglia di utilizzare una tabella di intersezione se nella colonna chiave esterna sono presenti molti valori NULL (ad esempio: se il 98% dei dipendenti non gestire un dipartimento)

Quando ci sono molti valori NULL nella colonna chiave esterna, i tuoi programmi dovranno occuparsi di questa colonna per lo più vuota per ogni record che elaborano. La colonna occuperà probabilmente un po 'di spazio su disco anche se nel 98% dei casi è vuota, interrogare la relazione significa interrogare quella colonna che ti dà più traffico di rete e se stai usando un ORM che genera le classi dalle tue tabelle, i tuoi programmi avrà anche bisogno di più spazio sul lato client del necessario. L'uso di una tabella di intersezione evita questo, ci saranno solo i record di link necessari dove altrimenti la chiave esterna equivalente non sarebbe NULL.

Al contrario, se non hai solo pochi valori NULL, diciamo che il 50% o più relazioni non sono NULL, l'uso di una tabella di intersezione ti dà l'effetto opposto: più spazio su disco, maggiore complessità con conseguente più traffico di rete ecc.

Quindi utilizzare una tabella di intersezione è solo una forma di ottimizzazione, sensata solo per un caso specifico, e soprattutto al giorno d'oggi, in cui lo spazio su disco e la memoria sono diventati più economici, molto meno frequentemente necessari. Si noti che "Fondamenti dei sistemi di database" è stato originariamente scritto più di 20 anni fa (ho trovato un riferimento alla seconda edizione del 1994) e immagino che la raccomandazione fosse già lì in quel momento. Prima del 1994, l'ottimizzazione dello spazio era probabilmente molto più importante di oggi, poiché l'archiviazione di massa era ancora più costosa e i computer e le reti erano molto più lenti di oggi.

Come nota a margine di un commento schizzinoso: la precedente affermazione sta solo cercando di anticipare ciò che l'autore di "Fundamentals of Database Systems" aveva in mente con la sua raccomandazione, immagino che stesse facendo una dichiarazione generale approssimativa, valida per la maggior parte dei sistemi. In alcuni database ci sono altre possibili ottimizzazioni come "colonne sparse" che rendono ancora più obsoleto l'uso di una tabella di intersezione.

Quindi non fraintendere quella raccomandazione. Il libro non ti dice di preferire le tabelle di intersezione per le {0,1}:nrelazioni in generale, o - come hai scritto - che questo è il "modo corretto". Usa ottimizzazioni come questa che renderanno i tuoi programmi più complicati solo quando ne avrai davvero bisogno.

Il modello concettuale sarà simile a questo, il che è molto poco ortodosso per non dire altro:

Il modello fisico sarà simile a questo, il che è confuso a dir poco (le persone penseranno che sia M: M a meno che non vedano da vicino):

Il mio consiglio:

Se ne hai, molte colonne (FK o altro), che non si applicano alla maggior parte degli studenti, separano le tabelle in tabelle dei ruoli con rel 1: 1. Ma non è perché sono FK, è perché le colonne non si applicano alla maggior parte delle righe.

Altrimenti , l' FK nullable è una parte normale di un database e le tabelle di join sono in genere per M: M rels.

Gli usi comuni delle rel 1: 1 sono per le tabelle dei ruoli con colonne applicabili solo se l'entità è di un certo tipo ed estrazione delle colonne BLOB per considerazioni su prestazioni o archiviazione. Avodificare i valori null negli FK non è un uso comune per questo.

Oltre ad altre risposte, vorrei sottolineare che un valore nullo per la chiave esterna è ambiguo. Significa:

1) La scuola dello studente (se presente) è sconosciuta (questo è il significato standard di 'null' - il valore è sconosciuto)

2) È noto se lo studente ha o meno una scuola e non ne hanno

Se usi il significato standard di null, come rappresenteresti "studente non ha scuola" nel tuo modello di chiave straniera. In tal caso, probabilmente dovresti creare una voce "nessuna scuola", con il suo ID nel tavolo della scuola. (Non ideale)

Le tabelle del database hanno questa bella cosa chiamata vincoli. Quindi è molto facile creare nella tabella di intersezione che consente a solo 1 di ogni studente di apparire nella tabella ma molte scuole in quella tabella. Dandoti efficacemente a

La teoria è buona ma alla fine modellerai il tuo database dopo le domande che stai ponendo.

Se vuoi fare spesso domande con la domanda: "quali studenti sono nella mia scuola", vuoi davvero interrogare l'intera tabella degli studenti o avere una tabella di intersezione semplice.

Nei database: ottimizza per le domande che fai.

Esiste un caso d'uso in cui l'utilizzo di una terza tabella può effettivamente avere senso. L'esempio può sembrare puramente ipotetico, ma spero che illustri bene il mio punto. Supponiamo che tu aggiunga più colonne alla studentstabella e ad un certo punto, decidi di applicare l'univocità sui record tramite l'indice composito su più colonne. È molto probabile che dovrai includere anche la school_idcolonna e qui le cose iniziano a diventare confuse. A causa del modo SQL creata, inserendo diversi dischi identici dove school_idè NULLsarà possibile. Ha perfettamente senso dal punto di vista tecnico, ma è controintuitivo e può portare a risultati inaspettati. D'altra parte, far rispettare l'unicità sul tavolo di intersezione è facile.

Di recente ho dovuto modellare una relazione "facoltativa", in cui il requisito per un vincolo di unicità era dovuto a una colonna timestamp. Lasciare la chiave esterna nullable nella tabella porta all'improvviso alla possibilità di inserire record con lo stesso timestamp (supponiamo che sia predefinito, impostato su record che non sono stati ancora controllati / approvati) - e l'unica via d'uscita era rimuovere colonna nullable.

Come puoi vedere, è un caso abbastanza specifico, e come altri hanno notato, la maggior parte delle volte saresti perfettamente a posto con tutti i NULLvalori. Dipende davvero dai requisiti specifici del tuo modello.

Oltre ai tanti buoni suggerimenti già presentati, personalmente non sono un fan delle chiavi esterne a meno che non siano veramente necessarie. Innanzitutto c'è la relazione M: M a cui stai facendo riferimento. Inoltre, la chiamata di una chiave esterna e quindi l'inserimento di tali dati nelle query, introduce maggiore complessità e, a seconda delle dimensioni della tabella, prestazioni più lente. Come altri hanno già detto, i campi FK nullable possono essere non supportati e possono creare problemi di integrità dei dati.

Se si sta definendo uno stato in cui la scuola studentesca è sconosciuta o vuota, il NULL non differenzierà tali condizioni. (di nuovo torniamo all'integrità dei dati.) Il suggerimento della tabella dei ruoli di Tulains è elegante e consente valori nulli in modo pulito.