Il problema qui è sottotipizzazione . Esistono tre approcci di base per gestire i sottotipi.
- Inserisci ogni tipo di record in una tabella completamente separata;
- Metti un record in una tabella padre e poi un record in una tabella di sottotipo; e
- Metti tutti i record in una tabella, con colonne nullable per i dati "facoltativi" (cioè cose che non si applicano a quel tipo).
Ogni strategia ha i suoi meriti.
Ad esempio, (3) è particolarmente applicabile se c'è poca o nessuna differenza tra i diversi sottotipi. Nel tuo caso, record di registro diversi hanno colonne aggiuntive se sono di un tipo particolare? Se non lo fanno o ci sono pochi casi in cui lo fanno, metterli tutti in una tabella ha perfettamente senso.
(2) è comunemente usato per una tabella Party. Questo è un modello comune nei CRM che coinvolge un oggetto Party padre che ha sottotipi per Persona e Organizzazione (l'organizzazione può anche avere sottotipi come Società, Associazione, ecc.). Persona e organizzazione hanno proprietà diverse (ad es. saluto, nomi dati, data di nascita, ecc. per Persona), quindi ha senso dividere questo aspetto piuttosto che utilizzare colonne annullabili.
(2) è potenzialmente più efficiente in termini di spazio (sebbene il sovraccarico delle colonne NULL nei moderni DBMS sia molto basso). Il problema più grande è che (2) potrebbe creare più confusione per gli sviluppatori. Otterrai una situazione in cui qualcuno ha bisogno di memorizzare un campo in più da qualche parte e lo colpirà in una colonna vuota per quel tipo semplicemente perché è più facile farlo che ottenere l'approvazione per i DBA per aggiungere una colonna (no, non sto scherzando ).
(1) è probabilmente lo schema meno utilizzato dei 3 nella mia esperienza.
Infine, la scalabilità deve essere considerata ed è probabilmente il caso migliore per (1). A un certo punto i JOIN non si ridimensionano in modo efficace e sarà necessario utilizzare una sorta di schema di partizionamento per ridurre le dimensioni della tabella. (1) è un metodo per farlo (ma un metodo grezzo).
Non mi preoccuperei troppo di questo però. In genere dovrai raggiungere centinaia di milioni o miliardi di record prima che diventi un problema (a meno che i tuoi record non siano davvero molto grandi, nel qual caso accadrà prima).
