Qual è la migliore progettazione del database:più tabelle o più colonne?[Chiuso]

StackOverflow https://stackoverflow.com/questions/59482

Domanda

Un ex collega insisteva sul fatto che un database con più tabelle con meno colonne ciascuna è migliore di uno con meno tabelle e più colonne ciascuna.Ad esempio, anziché una tabella clienti con nome, indirizzo, città, stato, CAP, ecc.colonne, avresti una tabella dei nomi, una tabella degli indirizzi, una tabella delle 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 fosse più efficiente, penso che questi vantaggi potrebbero essere controbilanciati dalla maggiore complessità.

Quindi, ci sono vantaggi significativi nel disporre di più tabelle con meno colonne rispetto a meno tabelle con più colonne?

È stato utile?

Soluzione

Ho alcune regole pratiche abbastanza semplici che seguo durante la progettazione di database, che penso possano essere utilizzate per prendere decisioni come questa....

  1. Favorire la normalizzazione.La denormalizzazione è una forma di ottimizzazione, con tutti i compromessi necessari, e come tale dovrebbe essere affrontata con un approccio YAGNI atteggiamento.
  2. Assicurarsi che il codice client che fa riferimento al database sia sufficientemente disaccoppiato dallo schema in modo che la sua rielaborazione non richieda una riprogettazione importante dei client.
  3. Non aver paura di denormalizzare quando fornisce un chiaro vantaggio in termini di prestazioni o complessità delle query.
  4. Utilizzare viste o tabelle downstream per implementare la denormalizzazione anziché denormalizzare il nucleo dello schema, quando il volume dei dati e gli scenari di utilizzo lo consentono.

Il risultato abituale di queste regole è che la progettazione iniziale favorirà le tabelle rispetto alle colonne, con l'obiettivo di eliminare la ridondanza.Man mano che il progetto avanza e vengono identificati i punti di denormalizzazione, la struttura complessiva evolverà verso un equilibrio che scende a compromessi con una ridondanza limitata e una proliferazione di colonne in cambio di altri preziosi vantaggi.

Altri suggerimenti

Sarei favorevole a più tavoli, ma solo fino a un certo punto.Usando il tuo esempio, se hai separato le informazioni dell'utente in due tabelle, ad esempio UTENTI e INDIRIZZO, questo ti dà la flessibilità di avere più indirizzi per utente.Un'ovvia applicazione di ciò è un utente che ha indirizzi di fatturazione e spedizione separati.

L'argomento a favore di avere una tabella CITY separata sarebbe che devi memorizzare il nome di ciascuna città solo una volta, quindi farvi riferimento 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 termini di join quando selezioni i dati dal tuo database.

Non sembra tanto una domanda su tabelle/colonne, ma sulla normalizzazione.In alcune situazioni hanno un alto grado di normalizzazione ("più tabelle" in questo caso) è buono e pulito, ma in genere è necessario un numero elevato di JOIN per ottenere risultati pertinenti.E con un set di dati sufficientemente grande, ciò può rallentare le prestazioni.

Jeff ha scritto qualcosa sulla progettazione di StackOverflow.Vedi anche il post a cui Jeff si collega Osate Obasanjo.

Una progettazione completamente normalizzata (ad esempio "Più 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.

Queste sono ragioni potenti per normalizzarsi.Sceglierei prima di normalizzare e poi solo di denormalizzare specifica tavoli Dopo hai visto che le prestazioni stavano diventando un problema.

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

Dipende dal tipo 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 rientrare in quella categoria.

Ogni tabella deve includere solo colonne relative all'entità identificata in modo univoco dalla chiave primaria.Se tutte le colonne nel database sono tutti attributi della stessa entità, allora avrai bisogno solo di una tabella con tutte le colonne.

Se una qualsiasi delle colonne può essere nulla, 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, è probabile che tu debba aggiungere più tabelle che colonne alle tabelle esistenti.Inoltre, aggiungendo questi attributi facoltativi alla propria tabella, non avrebbero più bisogno di consentire valori null e si eviterebbero una serie di problemi relativi ai NULL.

Il database multitabella è molto più flessibile se una qualsiasi di queste relazioni uno a uno può diventare uno a molti o molti a molti in futuro.Ad esempio, se devi memorizzare più indirizzi per alcuni clienti, è molto più semplice avere 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 tabelle separate di indirizzo, città, stato e codice postale potrebbero essere un po' esagerate.

Come tutto il resto:dipende.

Non esiste una regola ferrea per quanto riguarda il conteggio delle colonne rispetto al conteggio delle tabelle.

Se i tuoi clienti devono avere più indirizzi, è logico creare una tabella separata.Se hai una buona ragione per normalizzare la colonna Città nella sua tabella, allora anche questo può andare bene, ma non l'ho mai visto prima perché è un campo in formato libero (di solito).

Un tavolo dal design pesante e normalizzato è efficiente in termini di spazio e sembra "buono da libro di testo", ma può diventare estremamente complesso.Sembra carino finché non devi fare 12 join per ottenere il nome e l'indirizzo di un cliente.Questi disegni non lo sono automaticamente fantastico in termini di prestazioni che contano di più:interrogazioni.

Se possibile, evita la complessità.Ad esempio, se un cliente può avere solo due indirizzi (non arbitrariamente molti), potrebbe avere senso mantenerli tutti in un'unica tabella (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity, ecc.).

Ecco il post di Jeff sull'argomento.

Ci sono vantaggi nell'avere tabelle con meno colonne, ma devi anche esaminare lo scenario sopra e rispondere a queste domande:

Al cliente sarà consentito avere più di 1 indirizzo?In caso contrario, non è necessaria una tabella separata per gli indirizzi.Se è così, allora una tabella separata diventa utile perché puoi facilmente aggiungere più indirizzi secondo necessità lungo il percorso, dove diventa più difficile aggiungere più colonne alla tabella.

Considererei la normalizzazione come primo passo, quindi città, contee, stati, paesi sarebbero meglio come colonne separate...la potenza del linguaggio SQL, insieme agli attuali DBMS-es, ti consente di raggruppare i tuoi dati in un secondo momento se hai bisogno di visualizzarli in qualche altra vista non normalizzata.

Quando il sistema è in fase di sviluppo, potresti prendere in considerazione l'idea di "denormalizzare" alcune parti se lo consideri un miglioramento.

Penso che in questo caso ci sia equilibrio.Se ha senso inserire una colonna in una tabella, inseriscila nella tabella, altrimenti non farlo.L'approccio dei tuoi colleghi aiuterebbe sicuramente a normalizzare il database, ma ciò potrebbe non essere molto utile se devi unire 50 tabelle insieme per ottenere le informazioni di cui hai bisogno.

Immagino che la mia risposta sarebbe: usa il tuo miglior giudizio.

Ci sono molti aspetti in questo, ma dal punto di vista dell'efficienza dell'applicazione le tabelle mote possono essere più efficienti a volte.Se hai alcune tabelle con un mucchio di colonne ogni volta che il db esegue un'operazione ha la possibilità di creare un blocco, più dati verranno resi non disponibili per la durata del blocco.Se i blocchi vengono intensificati alla pagina e alle tabelle (beh, si spera, non alle tabelle :)), puoi vedere come ciò può rallentare il sistema.

Hmm.

Penso che sia un lavaggio e dipenda dal tuo particolare modello di design.Sicuramente escludere le entità che hanno più di pochi campi nella propria tabella, o entità la cui composizione probabilmente cambierà man mano che cambiano i requisiti dell'applicazione (ad esempio, escluderei comunque l'indirizzo, poiché ha così tanti campi, ma io 'D particolarmente fallo se pensi che ci sia qualche possibilità di dover gestire indirizzi di paesi stranieri, che possono avere una forma diversa.Lo stesso con i numeri di telefono).

Detto questo, quando lo fai funzionare, tieni d'occhio le prestazioni.Se hai creato un'entità che richiede di eseguire unioni grandi e costose, forse diventa una decisione progettuale migliore riportare quella tabella nell'originale.

Ci sono enormi vantaggi interrogazioni utilizzando il minor numero di colonne possibile.Ma la tabella stessa può avere un numero elevato. Jeff dice qualcosa anche su questo.

Fondamentalmente, assicurati di non chiedere più del necessario quando esegui una query: le prestazioni delle query sono direttamente correlate al numero di colonne richieste.

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

Non vedo il vantaggio di avere una tabella delle città a meno che le città di per sé non siano entità a cui tieni nella tua applicazione.Oppure se vuoi limitare il numero di città a disposizione dei tuoi utenti.

La conclusione è che decisioni come questa devono prendere in considerazione l'applicazione stessa prima di iniziare a puntare all'efficienza.dell'IMO.

Quando progetti il ​​tuo database, dovresti essere il più vicino possibile al significato dei dati e NON alle esigenze della tua applicazione!

Una buona progettazione di database dovrebbe durare più di 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, è questione del design della tua applicazione e non dei dati!

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

La maggior parte delle volte avrai problemi di prestazioni con un database che riguarda le prestazioni della rete (query a catena con il risultato di una riga, recupera la colonna che non ti serve, ecc.) Non la complessità della tua query.

Innanzitutto, normalizza le tue tabelle.Ciò ti garantisce di evitare dati ridondanti, offrendoti meno righe di dati da scansionare, il che migliora le tue query.Quindi, se ti imbatti in un punto in cui le tabelle normalizzate che stai unendo causano un tempo di elaborazione della query troppo lungo (clausola di join costosa), denormalizza dove più appropriato.

È bello vedere così tante risposte stimolanti e ben basate.

La mia risposta sarebbe (purtroppo):dipende.

Due casi:* Se crei un modello di dati che verrà utilizzato per molti anni e quindi probabilmente dovrà subire molte modifiche future:scegli più tabelle e meno righe e una normalizzazione piuttosto rigorosa.* Negli altri casi puoi scegliere tra più tabelle-meno righe oppure meno tabelle-più righe.Soprattutto per le persone relativamente nuove all’argomento, 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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top