Quante colonne sono troppe colonne?

Question

Ho notato che molte persone citano le tabelle con più di 20 colonne (ho visto fino a 55) in una tabella. Ora non pretendo di essere un esperto di database design, ma ho sempre sentito che questa è una pratica orribile. Quando vedo questo, di solito suggerisco di suddividere in due tabelle con una relazione uno a uno: una contenente i dati più frequentemente utilizzati, l'altra con i dati meno utilizzati. Anche se, allo stesso tempo, c'è il possibile problema delle prestazioni (meno JOIN e così via). Quindi la mia domanda è questa:

Quando si tratta di database di grandi dimensioni, è davvero un vantaggio avere una grande quantità di colonne, nonostante questo di solito porta a molti valori NULL?

che è più di un calo di prestazioni: un sacco di colonne con un sacco di Null, o un minor numero di colonne con un sacco di join?

Answer 1

Il design del tavolo dipende l'entità di cui ha bisogno per memorizzare. Se tutti i dati appartengono insieme, allora 50 colonne (o anche 100) potrebbero essere la cosa giusta da fare.

Fintanto che la tabella è normalized, non esiste una regola empirica per quanto riguarda le dimensioni, a parte le funzionalità del database e la necessità di ottimizzare.

Answer 2

Sono d'accordo con Oded. Ho visto tabelle con 500 colonne al loro interno e tutte le colonne in esse erano nel posto giusto. Basta considerare il numero di fatti che si potrebbero desiderare di archiviare su un oggetto quotidiano, e presto capirai perché.

Se risulta inopportuno selezionare tutte quelle colonne o specificare quali colonne selezionare quando si è interessati solo a una piccola parte di esse, potrebbe essere utile definire una vista.

Answer 3

che è più di un calo di prestazioni: un sacco di colonne con un sacco di Null, o meno colonne con un sacco di join?

Dipende esclusivamente dai dati archiviati, dagli indici effettuati e così via. Nessuno può assicurarti che uno funzioni meglio di un altro senza sapere cosa stai memorizzando. Generalmente le regole di normalizzazione "costringono" a separare i dati su diverse tabelle e FKeys utente se si dispone di una tabella di grandi dimensioni, ma non sono d'accordo sul fatto che SEMPRE funzioni meglio di una tabella grande. È possibile terminare con join di livello 6-7 in dozzine di query che a volte causano errori perché ci sono molte più possibilità di creare un errore nelle query più grandi che in quelle semplici.

Se pubblichi alcuni requisiti di ciò che si sta facendo forse possiamo aiutarvi con la progettazione del DB correttamente.

Answer 4

odbc ha un limite di caratteri di 8000 .... quindi questo è un limite fisico oltre il quale le cose diventano estremamente frustranti.

ho lavorato su un tavolo che ha avuto 138 colonne .. era orribilmente scritto e avrebbe potuto essere normalizzato. Anche se questo database sembra essere stato la creazione di qualcuno che si chiede perché ci siano convenzioni nella progettazione del database e decidiamo di testarle tutte insieme.

Avere tabelle molto larghe e appiattite è abbastanza comune quando si entra nei server di data warehousing e reporting. Sono solo molto più veloci e significano che non è necessario memorizzare il database interamente nella RAM per le prestazioni.

Answer 5

Quante colonne sono troppe colonne?

Quando senti che non ha più senso o è giusto aggiungere un'altra colonna.

Generalmente dipende dall'applicazione.

Answer 6

Secondo la mia esperienza è meglio avere meno join in quanto tendono ad accadere troppo spesso soprattutto in un grande database. Finché le tabelle del database sono progettate per memorizzare entità singola (studente, insegnante e così via), questo dovrebbe essere ok. In modo che questo verrà rappresentato come un oggetto nel codice in seguito. Quindi, se dividi l'entità in più tabelle dovrai utilizzare diversi join per riempire il tuo oggetto in un secondo momento. Inoltre, se si utilizza ORM per generare il proprio livello di accesso ai dati (come Linq in .Net) si genereranno classi separate per ogni tabella (ovviamente con una relazione tra loro ma ancora) e questo sarà più difficile da utilizzare.

Un'altra cosa è che è possibile specificare le colonne da restituire nella query e questo ridurrà i dati passati all'applicazione, ma se è necessaria anche una singola colonna da un'altra tabella, sarà necessario effettuare il join. E nella maggior parte dei casi in quanto hai così tante colonne, la probabilità di avere una grande quantità di dati memorizzati nel db è alta. Quindi questo join danneggerebbe di più dei NULL.

Ogni progetto su cui ho lavorato è diverso, quindi dovresti trovare il saldo per ogni storia.

Answer 7

Inoltre dipende molto dal pacchetto di utilizzo per il tuo tavolo. Se si desidera ottimizzarlo per la lettura, potrebbe essere una buona idea tenere tutto insieme in una tabella.

Nel mondo NO-SQL (cassandra/hbase per esempio) non ci sono vincoli sul numero di colonne e in realtà è considerato una buona pratica avere molte colonne. Ciò deriva anche dal modo in cui è memorizzato (senza spazi vuoti). Vale la pena investigare.

Answer 8

È preferibile utilizzare una singola tabella in cui è possibile evitare l'utilizzo di join mentre la query dipende dal fatto che le colonne siano della stessa entità o entità diversa.

Ad esempio, si presuppone che si stia eseguendo una progettazione di database per il flusso di lavoro in cui alcuni campi saranno modificati da lavoratori junior e alcuni campi da lavoratori senior. In questo caso è meglio avere tutte le colonne in una singola tabella.

Answer 9

Avere troppe colonne produce un lotto null (male) e un oggetto pesante a cui è associata la tabella. Ciò danneggia la leggibilità dell'IDE e ostacola la manutenzione (aumento dei costi di sviluppo). Se hai bisogno di letture veloci, in alcuni casi usa tabelle denormalizzate per es. utilizzato esclusivamente per rapporti o query (cercare il modello "CQRS"). Sì "Persona" ha un milione di attributi, ma puoi abbattere queste tabelle monottiche (design precede la normalizzazione) per abbinare le entità più piccole ("indirizzo", "telefono", "hobby") invece di aggiungere nuove colonne per ogni nuovo caso d'uso. Avere oggetti di dimensioni più piccole (e tabelle) porta così tanti vantaggi; abilitano le cose come test di unità, OOP e pratiche SOLID.

Inoltre, per quanto riguarda il raggruppamento di numerose colonne per evitare join, ritengo che il guadagno in termini di prestazioni derivante dall'evitare i join venga perso tramite la manutenzione dell'indice, presupponendo un carico di lavoro tipico di letture e scritture. L'aggiunta di indici sui campi per motivi di prestazioni di lettura potrebbe essere indicativo della necessità di spostare tali campi nella propria tabella.