Progettazione database: un grande tavolo rispetto a diversi tavoli più piccoli

Question

Devo creare un database per archiviare le informazioni inviate e ricevute a/da un portale di servizi Web di terze parti. Ci sono circa 150 campi di informazione da inviare anche se posso rimuovere circa 50 di questi campi normalizzandoli (ci sono tre serie di indirizzi che possono essere salvati in una tabella di indirizzi, per esempio). Tuttavia, questo lascia comunque una tabella che potrebbe potenzialmente contenere 100 colonne.

mi è venuta in mente due modi di gestire questo anche se non sono sicuro di quale utilizzare:

. Avere una tabella con 100 colonne e tre riferimenti a una tabella di indirizzi.

. Scomponilo in forse 15-20 tavoli dedicati separati.

L'opzione 1 sembra la più veloce in quanto comporta il minor numero di join ma l'idea di un tavolo con 100 colonne non sembra corretta.

L'opzione 2 si sente meglio e rompe le cose in parti più gestibili ma non salverà nessuno spazio del database e aumenterà il numero di join. Praticamente tutte le colonne nel database avranno un valore e non posso più normalizzare queste colonne.

La mia domanda è, in questa situazione è accettabile avere una tabella con colonne di c.100 in esso o dovrei provare a scomporlo su più tabelle per la presentazione?

Nota: La struttura della tabella non cambierà nel corso del suo utilizzo, verrà creato un nuovo database per una nuova versione del portale dei servizi Web. Non ho alcun controllo sulla struttura dei dati del servizio web.

Modifica: @ La risposta di Oded di seguito mi ha fatto riflettere un po 'più su come i dati saranno accessibili; sarà veramente accessibile solo in parte e non in parte. Ad esempio, non dovrei restituire regolarmente le colonne 5-20.

Risposta: Ho accettato risposta Oded sulla base dei commenti dopo aver postato mi ha aiutato a rendere la mia mente e ho deciso di andare con l'opzione 1. Poiché i dati si accede in pieno, quindi avere un tavolo sembra la soluzione migliore . Se, ad esempio, volevo regolarmente accedere alle colonne 5-20 anziché alla riga completa della tabella, vedrei di dividerlo in tabelle separate per motivi di prestazioni.

Answer 1

Parlando da un punto di vista purista relazionale - in primo luogo, non c'è nulla contro l'avere 100 colonne in una tabella, se sono correlate. Il punto qui è che se dopo normalizing hai ancora 100 colonne, va bene.

Ma si si dovrebbe normalizzare e nel processo si può benissimo finire con 15-20 tabelle dedicate separate, che la maggior parte dei professionisti del database relazionale sarebbe d'accordo è un design migliore (evitare la duplicazione dei dati con i problemi di aggiornamento/eliminazione associato, impronta di dati più piccola ecc ...).

Pragmaticamente, tuttavia, se è presente un problema di prestazioni misurabili, potrebbe essere ragionevole per denormalizzare il modello per ottenere vantaggi in termini di prestazioni. La chiave qui - misurabile. Non ottimizzare prima di avere un problema reale.

In questo senso, direi che dovresti utilizzare il set di 15-20 tabelle come progetto iniziale.

Answer 2

Da MSDN: Maximum Capacity Specifications for SQL Server:

colonne per tabella nonwide: 1,024

colonne per tabella ampia: 30.000

Quindi penso che 100 colonne è ok nel tuo caso. E anche forse avete bisogno di nota (da stesso link):

Colonne per chiave primaria: 16

Naturalmente questo è solo nel caso in cui hanno bisogno di dati solo come log per un servizio.

Se dopo aver letto dal servizio è necessario mantenere i dati -> quindi normalizzare sembra meglio ...

Answer 3

Se si trova più facile da "gestire" le tabelle con un minor numero di colonne, tuttavia vi capita di definire gestibilità (ad esempio, meno scorrimento orizzontale quando si guardano i dati della tabella in SSMS), è possibile suddividere il tavolo in più tabelle con relazioni 1-a-1 senza violare le regole di normalizzazione.