Qual è il design del database migliore: più tabelle o più colonne?

Un ex collega ha insistito sul fatto che un database con più tabelle con meno colonne ciascuna è migliore di quello con meno tabelle con più colonne ciascuna. Ad esempio, piuttosto che una tabella clienti con colonne nome, indirizzo, città, stato, zip, ecc., Avresti una tabella dei nomi, una tabella degli indirizzi, una tabella della città, ecc.

Ha sostenuto che questo progetto era più efficiente e flessibile. Forse è più flessibile, ma non sono qualificato per commentare la sua efficienza. Anche se è più efficiente, penso che quei guadagni possano essere superati dalla maggiore complessità.

Quindi, ci sono dei vantaggi significativi per più tabelle con meno colonne su un numero inferiore di tabelle con più colonne?

Vorrei discutere a favore di più tabelle, ma solo fino a un certo punto. Usando il tuo esempio, se hai separato le informazioni dell’utente in due tabelle, ad esempio USERS e ADDRESS, questo ti dà la flessibilità di avere più indirizzi per utente. Una ovvia applicazione di questo è un utente che ha indirizzi di fatturazione e spedizione separati.

L’argomento a favore di avere una tabella CITY separata sarebbe che devi solo memorizzare il nome di ogni città una volta, quindi fare riferimento ad esso quando ne hai bisogno. Ciò riduce la duplicazione, ma in questo esempio penso che sia eccessivo. Potrebbe essere più efficiente in termini di spazio, ma pagherai il prezzo in join quando selezioni i dati dal tuo database.

Non suona molto come una domanda su tabelle / colonne, ma sulla normalizzazione. In alcune situazioni, un elevato grado di normalizzazione (“più tabelle” in questo caso) è buono e pulito, ma in genere richiede un numero elevato di JOIN per ottenere risultati rilevanti. E con un set di dati abbastanza grande, questo può impantanare le prestazioni.

Jeff ha scritto qualcosa riguardo al design di StackOverflow. Vedi anche il post che Jeff collega a Dare Obasanjo .

Un design completamente normalizzato (ad esempio, “Altre tabelle”) è più flessibile, più facile da mantenere ed evita la duplicazione dei dati, il che significa che l’integrità dei dati sarà molto più semplice da applicare.

Quelli sono motivi potenti per normalizzare. Vorrei prima scegliere di normalizzare e quindi denormalizzare solo tabelle specifiche dopo aver visto che il rendimento stava diventando un problema.

La mia esperienza è che nel mondo reale non si raggiunge il punto in cui è necessaria la denormalizzazione, anche con insiemi di dati molto grandi.

Dipende dal tuo sapore di database. MS SQL Server, ad esempio, tende a preferire tabelle più strette. Questo è anche l’approccio più ‘normalizzato’. Altri motori potrebbero preferire il contrario. I mainframe tendono a cadere in quella categoria.

Ogni tabella deve includere solo le colonne relative all’entity framework che è identificata in modo univoco dalla chiave primaria. Se tutte le colonne nel database sono tutti gli attributi della stessa quadro, allora avrai solo bisogno di una tabella con tutte le colonne.

Se una qualsiasi delle colonne può essere nullo, tuttavia, sarà necessario inserire ciascuna colonna nullable nella propria tabella con una chiave esterna nella tabella principale per normalizzarla. Questo è uno scenario comune, quindi per un design più pulito, è preferibile aggiungere più tabelle che colonne a tabelle esistenti. Inoltre, aggiungendo questi attributi facoltativi alla propria tabella, non avrebbero più bisogno di consentire i null e si eviterebbe un gran numero di problemi relativi a NULL.

Il database multi-table è molto più flessibile se qualcuno di questi rapporti uno a uno può diventare uno a molti o molti a molti in futuro. Ad esempio, se hai bisogno di memorizzare più indirizzi per alcuni clienti, è molto più semplice se hai una tabella clienti e una tabella indirizzi. Non riesco davvero a vedere una situazione in cui potrebbe essere necessario duplicare alcune parti di un indirizzo ma non altre, quindi le tabelle separate di indirizzo, città, stato e zip potrebbero essere un po ‘esagerate.

Come tutto il resto: dipende.

Non esiste una regola rigida per quanto riguarda il conteggio delle colonne e il conteggio delle tabelle.

Se i tuoi clienti devono avere più indirizzi, allora una tabella separata ha senso. Se hai davvero un buon motivo per normalizzare la colonna City nella sua tabella, allora anche quella può andare, ma non l’ho mai vista prima perché è un campo di forma libera (di solito).

Un tavolo pesante, il design normalizzato è efficiente in termini di spazio e sembra “da manuale”, ma può diventare estremamente complesso. Sembra bello finché non devi fare 12 join per ottenere il nome e l’indirizzo di un cliente. Questi progetti non sono automaticamente fantastici in termini di prestazioni che contano di più: le query.

Evita la complessità se ansible. Ad esempio, se un cliente può avere solo due indirizzi (non arbitrariamente molti), allora potrebbe avere senso tenerli tutti in un’unica tabella (CustomerID, Nome, IndirizzoDestinazione, Indirizzo di fatturazione, IndirizzoDiCittà, BillingCity, ecc.).

Ecco il post di Jeff sull’argomento.

Ci sono dei vantaggi nell’avere tabelle con meno colonne, ma devi anche guardare il tuo scenario sopra e rispondere a queste domande:

Sarà consentito al cliente di avere più di 1 indirizzo? In caso contrario, non è necessaria una tabella separata per l’indirizzo. In tal caso, una tabella separata diventa utile perché è ansible aggiungere facilmente più indirizzi in base alle esigenze lungo la strada, dove diventa più difficile aggiungere più colonne alla tabella.

considererei la normalizzazione come il primo passo, quindi le città, le contee, gli stati, i paesi sarebbero migliori come colonne separate … la potenza del linguaggio SQL, insieme ai DBMS attuali consente di raggruppare i dati in un secondo momento se è necessario visualizzare in qualche altra vista non normalizzata.

Quando il sistema è in fase di sviluppo, potresti considerare la “denormalizzazione” di una parte se la vedi come un miglioramento.

Penso che l’equilibrio sia in ordine in questo caso. Se ha senso inserire una colonna in una tabella, quindi inserirla nella tabella, in caso contrario, non farlo. Il tuo approccio ai colleghi aiuterà sicuramente a normalizzare il database, ma potrebbe non essere molto utile se devi unire 50 tabelle per ottenere le informazioni di cui hai bisogno.

Immagino quale sarebbe la mia risposta, usa il tuo miglior giudizio.

Ci sono molti aspetti in questo, ma da un punto di vista dell’efficienza delle applicazioni le tabelle possono essere più efficienti a volte. Se si dispone di poche tabelle con un gruppo di colonne ogni volta che il db per eseguire un’operazione ha la possibilità di effettuare un blocco, più dati vengono resi non disponibili per la durata del blocco. Se i blocchi vengono sottoposti a un’escalation alla pagina e alle tabelle (si spera che non siano tabelle :)) è ansible vedere come questo può rallentare il sistema.

Hmm.

Penso che sia un lavaggio e dipende dal tuo particolare modello di design. Definisci definitivamente le quadro che hanno più di alcuni campi nella loro tabella, o entity framework il cui trucco probabilmente cambierà quando i requisiti della tua applicazione cambiano (ad esempio – Tralascio comunque l’indirizzo, dato che ha così tanti campi, ma io Lo farei soprattutto se pensavi che ci fosse qualche possibilità di gestire indirizzi di paesi stranieri, che possono essere di una forma diversa, lo stesso con i numeri di telefono).

Detto questo, quando lo fai funzionare, tieni d’occhio le prestazioni. Se hai fatto fuoriuscire un’entity framework che richiede di realizzare join costosi e di grandi dimensioni, forse è meglio prendere una decisione di progettazione per far rientrare quel tavolo nell’originale.

Ci sono enormi vantaggi per le query utilizzando il minor numero ansible di colonne. Ma il tavolo stesso può avere un numero elevato. Jeff dice qualcosa anche su questo.

Fondamentalmente, assicurati di non chiedere più del necessario quando fai una query: l’esecuzione delle query è direttamente correlata al numero di colonne che chiedi.

Penso che devi guardare il tipo di dati che stai memorizzando prima di prendere questa decisione. Avere una tabella degli indirizzi è ottima ma solo se la probabilità che più persone condividano lo stesso indirizzo è alta. Se ogni persona ha indirizzi diversi, mantenere i dati in una tabella diversa introduce solo join non necessari.

Non vedo il vantaggio di avere un tavolo da città a meno che le città in se stesse siano quadro a cui tieni a cuore nella tua applicazione. O se vuoi limitare il numero di città disponibili per i tuoi utenti.

La conclusione è che decisioni come questa devono prendere in considerazione l’applicazione stessa prima di iniziare a scattare per l’efficienza. IMO.

Quando progetti il ​​tuo database, dovresti essere il più vicino ansible dal significato dei dati e NON hai bisogno della tua applicazione!

Un buon progetto di database dovrebbe durare oltre 20 anni senza modifiche.

Un cliente potrebbe avere più indirizzi, questa è la realtà. Se hai deciso che la tua applicazione è limitata a un indirizzo per la prima versione, è importante il design della tua applicazione, non i dati!

È meglio avere più tabelle anziché più colonne e utilizzare la visualizzazione se si desidera semplificare la query.

Nella maggior parte dei casi, il problema delle prestazioni con un database riguarda le prestazioni della rete (query a catena con risultato di una riga, colonna di recupero non necessaria, ecc.) Non sulla complessità della query.

In primo luogo, normalizza le tue tabelle. Ciò garantisce di evitare i dati ridondanti, fornendo meno righe di dati da analizzare, migliorando le query. Quindi, se ci si imbatte in un punto in cui le tabelle normalizzate a cui si sta partecipando provocano una lunga elaborazione della query (costosa clausola join), denormalizzare la posizione più appropriata.

È bello vedere tante risposte ispiratrici e ben fondate.

La mia risposta sarebbe (sfortunatamente): dipende.

Due casi: * Se si crea una datamodel che deve essere utilizzata per molti anni e quindi è probabile che sia necessaria molte modifiche future: andare su più tabelle e meno righe e una normalizzazione piuttosto rigida. * In altri casi puoi scegliere tra più tabelle senza tabelle o meno tabelle, più righe. Soprattutto per le persone relativamente nuove al tema, quest’ultimo approccio può essere più intuitivo e facile da comprendere.

Lo stesso vale per la scelta tra l’approccio orientato agli oggetti e altre opzioni.