Progettazione database - campi vuoti

Question

Attualmente sto discutendo di un problema con il mio team di sviluppo. Credono che i campi vuoti siano cattive notizie. Ad esempio, se disponiamo di una tabella dei dettagli del cliente che memorizza i dati per i clienti di paesi diversi e ogni paese ha una configurazione dell'indirizzo leggermente diversa, più 1-2 campi aggiuntivi, ad es. I dettagli dei clienti francesi possono anche memorizzare i dettagli per il codice di accesso e i campi di livello base/livello più (madamme, ecc.). Il Sudafrica avrebbe un numero di sicurezza. E così via.

Dato che stiamo parlando di piccole differenze, la mia idea è di inserire tutti i campi nella tabella e utilizzare ciò che è necessario su ogni modulo.

Il mio collega ritiene che dovremmo avere una tabella separata con dati aggiuntivi. Per esempio. customer_info_fr. Ma questo giura di sconfiggere completamente lo scopo di un tavolo combinato in primo luogo.

L'argomento è che campi/colonne vuoti sono errati, ma sto cercando di trovare una giustificazione in termini di principi di progettazione del database a favore o contro questo argomento e le soluzioni preferite.

Un'altra opzione è una tabella mini EAV separata che memorizza dati aggiuntivi con parent_id, chiave, campi val. O per serializzare dati extra in una colonna extra_data nella tabella customer_data principale.

Penso di essere confuso perché quello di cui sto discutendo non è coperto da 3NF, che è quello che userei tipicamente come riferimento per come strutturare i dati.

Quindi la mia domanda in particolare: -

Se si dispone di lievi variazioni nei dati per ogni record (1-2 campi diversi per esempio) che cosa è il modo migliore di procedere?

Answer 1

Null invariabilmente aggiungono complessità ad un modello di dati perché il comportamento di null in SQL corrisponde raramente la matematica, logica o realtà che si intende modellare con esso. In altre parole, alcune query restituiscono risultati errati, che è necessario compensare con logica aggiuntiva.

Tutte le informazioni possono essere rappresentate con precisione senza valori nulli. Poiché i null aggiungono complessità, è pratica del buon design avviare il modello di dati senza di essi e quindi aggiungere solo un valore null in cui si trova qualche motivo speciale per farlo o dove alcune funzionalità o limitazioni del database impongono un valore nullo.

Answer 2

Ecco a cosa servono i campi nullable: "Dati non disponibili/applicabili".

SQL ha una nozione diversa di null rispetto alla maggior parte dei linguaggi di programmazione, quindi il null di SQL è spesso un concetto frainteso.

Answer 3

Sarei interessato alla giustificazione del collega sul motivo per cui i campi vuoti sono negativi. Per quanto ne so, i campi vuoti o nulli non sono male di per sé. Se disponi di molti valori di dati vuoti per una colonna su cui stai pianificando l'inserimento di un indice importante, potresti prendere in considerazione altre opzioni. Questo vale per qualsiasi colonna in cui si hanno effettivamente molti record duplicati e serve un indice, come record duplicati lower the cardinality della colonna, rendendo gli indici meno utili. Nel tuo caso, non vedo che sia un problema.

Per questo tipo di dati, è probabile che si utilizzi un VARCHAR o un tipo di colonna TEXT, che sono campi di lunghezza variabile nel database. Non importa se il tuo campo è pieno di dati o vuoto, dovrai comunque sostenere l'overhead di una colonna di lunghezza variabile (che non vale la pena di preoccuparsi in circostanze normali). Quindi, ancora una volta, non c'è differenza per l'RDBMS.

Dai suoni di ciò che si sta progettando, penso che se si fosse usciti con un metodo generico di gestione delle varianze degli indirizzi in una singola tabella, sarebbe la strada da percorrere. Il tuo codice e la tua struttura sarebbero molto più semplici rispetto al costo trascurabile (a mio avviso) di alcuni campi di dati vuoti.

Answer 4

C'è sicuramente una scuola di pensiero che ritiene che i campi NULL siano cattivi, dentro e di se stessi. La teoria relazionale richiede che i database siano fatti di fatti, e i NULL sono l'assenza di fatti. Quindi, un database progettato in modo rigoroso non avrebbe colonne nullable.

Il suo collega sta proponendo qualcosa che si trova sulla strada per 6 forma normale, in cui tutti i tavoli sono costituiti da una chiave primaria e al massimo un altra colonna. Solo in tale schema non avremmo tabelle chiamate customer_info_fr. Questo non è normalizzato. Molti paesi potrebbero includere ENTRY_CODE in questi indirizzi. Quindi avremmo bisogno di address_entry_codes e address_floor_numbers. Per non parlare di address_building_number e address_building_name, in quanto alcuni posti sono identificati dal numero e altri dal nome.

E 'completamente accurato e veritiero come un disegno logico. Purtroppo da una prospettiva fisica è Teh Suck! La query più semplice - select * from addresses - diventa un join a più tabelle e join esterni a quello. Le colonne imbattibili sono un modo per riconciliare il design brutto con la dura verità, "non puoi infrangere le leggi della fisica". Le colonne Nullable ci consentono di combinare insiemi di dati disgiunti in una singola tabella, anche se a costo di gestire valori nulli (possono influire sul recupero dei dati, sull'uso dell'indice, sulla matematica, ecc.).

Answer 5

Qualsiasi cosa tu faccia, non scendere lungo il percorso EAV. Questa è una prescrizione per un database mal funzionante, molto, molto peggio di alcuni campi vuoti.

Se è necessario disporre di un separato tabelle correlate per le diverse situazioni, un sacco di che dipenderà da come i diversi soggetti sono e come sarà interrogato. Se eseguirai una query tra le categorie, scoprirai che l'accesso a un gruppo di tabelle per ottenere tutti i dati di cui potresti avere bisogno o meno potrebbe essere un incubo (non so se la Germania sarà nel mio set di risultati, quindi mi unisco a le tabelle di dettagli Germania, oops non ha bisogno di). Può essere molto più semplice gestire i valori nulli che provare a capire a quale delle molte tabelle è necessario unirsi (e ricordarsi sempre di lasciare unirsi a quelle tabelle).

Tuttavia, se non si sarà mai eseguendo la query attraverso le entitites ei campi a dare un senso a parte, poi metterli in una tabella separata.