Qual è un buon modo per memorizzare un gran numero di colonne?

Ho un problema nel decidere come archiviare questi dati nel mio database. Qualche suggerimento sul modo migliore per farlo? Non ne so molto dei database, potrei aggiungere.

Ho i dati in arrivo formattati in questo modo, ma anziché 4, il numero di colonne è di circa 240, quindi ad ogni data sono associati 240 valori univoci:

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

Inoltre, le righe sono associate a DataSites.

Il mio primo pensiero è stato quello di avere una tabella in questo modo: DataID (pk), DataSiteID, ParameterID, Date, Value, con un indice su DataSite, Parameter e Date. L'ID parametro si riferisce a un'altra tabella che memorizza le intestazioni della colonna di input (200,00 202,50 205,00 ...).

Il mio secondo pensiero era semplicemente di avere una tabella con tutte le 240 colonne dispari. Ho escogitato alcuni altri modi, ma sono anche abbastanza insoddisfacenti.

Il problema che ho con la mia prima soluzione (non un problema così grande, ma non mi piace), è che la Data e il DataSiteID verranno ripetuti per tutti i 240 valori in quella riga di input, quindi usa un po ' di spazio extra.

Ci saranno circa 40 GB di dati all'anno in arrivo (nel formato di testo sopra) e i dati verranno cercati per DataSite, Parametro e Data. La quantità di dati in arrivo molto probabilmente quadruplicherà in circa un anno.

Qualche buona idea? Grazie James

modifica: si tratta di dati di serie temporali, con le colonne misurate a lunghezze d'onda diverse. I dati vorranno essere analizzati in un intervallo relativamente ristretto di lunghezze d'onda. Potrebbero anche essere aggiunte lunghezze d'onda aggiuntive in futuro.

modifica: Grazie per le risposte ragazzi, lo apprezzo davvero :) Penso che probabilmente riuscirò a trovare il tempo per eseguire alcuni esperimenti con circa 500 GB di dati di test. Riporterò indietro con qualsiasi conclusione;)

Puoi fare un caso in entrambi i casi, ma se i dati verranno utilizzati per l'analisi e spesso vuoi vedere più colonne da quei dati contemporaneamente, vai con la tabella ampia. Assicurati di conoscere i limiti di quantità e dimensioni delle colonne del database. Assicurati di ottenere i tipi di dati giusti. Se molte delle colonne sono nulle, SQL Server ti consente di ottimizzare la tabella. Si potrebbe anche considerare l'utilizzo di una soluzione NOSQL (non solo SQL) per l'analisi di questo tipo di dati.

Se questi dati saranno meno per l'analisi, potresti voler normalizzarli come indicato nella tua domanda.

Ho avuto una situazione molto simile alla tua, 257 campi con 30-50 GB all'anno. Ho finito per mantenerlo semplice, un lungo tavolo da ragazzi in SQL Server. I miei dati sono stati interrogati abbastanza, ma soprattutto per data e ha funzionato bene.

Avrei potuto suddividere i dati in mandrini più piccoli logici (gruppi di circa 50 o giù di lì), ma in questo caso non c'era davvero un grande vantaggio, quindi mi sono risparmiato il disturbo.

Se ora mi sentissi di fantasia, potrei prendere in considerazione un'opzione NoSQL che si adatta meglio alla teoria, ma con dati mission-critical che provano nuove cose non è sempre ottimo per i nervi.

Quindi, per rispondere tardivamente alla mia domanda (il progetto non è mai andato avanti alla fine), quando sono riuscito a guadagnare un po 'di tempo libero ho riempito una tabella di test con 500 g di dati con la tabella organizzata in questo modo:

Il mio primo pensiero è stato quello di avere una tabella in questo modo: DataID (pk), DataSiteID, ParameterID, Date, Value, con un indice su DataSite, Parameter e Date. L'ID parametro si riferisce a un'altra tabella che memorizza le intestazioni della colonna di input (200,00 202,50 205,00 ...).

L'impostazione del database era l'installazione PostgreSQL standard su una vecchia macchina dual core con 3 GB di RAM. Ho eseguito una dozzina di query diverse selezionando semplicemente i dati per Data Data e Parameter ID, calcolando la media dei dati su un periodo di 1 ora, un periodo di 1 giorno e inserendo nuovi blocchi di dati. Dalla memoria, l'esecuzione di tutte le query ha richiesto meno di un secondo. Era certamente molto più veloce di quanto mi aspettassi e abbastanza utilizzabile. Una cosa a cui non avevo pensato era che con la tabella indicizzata in questo modo anche il file di indice era quasi 500 GB, quindi avere una tabella larga 240 colonne avrebbe sicuramente risparmiato molto spazio su disco.

In Postgres lo risolverei elegantemente con un tipo di array o una variante in Oracle.

Non so se sia utile per il tuo problema, ma per le colonne non ho bisogno di fare richieste dirette (cols che non ho mai messo nella mia condizione WHERE) e che sono solo informative quando voglio tutte le informazioni su alcuni righe specifiche, le combino in un campo blog formattato JSON.

Probabilmente prenderei la decisione finale del progetto in base alla distribuzione dei parametri_ID interrogati. Cioè, se ci sono alcuni parametri_ids che vengono interrogati quasi esclusivamente, metterei i loro valori in una tabella calda e i valori rimanenti in un'altra tabella fredda .

Otoh, se la loro distribuzione delle query è più o meno uniforme, caricare un set di campioni del valore di alcuni giorni in una tabella in cui un record mantiene tutti i valori per vedere quale sia il rapporto tra record / blocchi db (o se c'è anche un problema di concatenamento di file , che è probabile). A seconda di ciò, farei un'ulteriore decisione di progettazione.

Bene, dopo averlo letto, probabilmente farei entrambi gli approcci per una decisione in parallelo.

Stavo rileggendo la domanda - se ho questo corretto, quindi in ogni record che ottieni come input, ci sono diversi valori da tracciare (in base al ParameterID):

L'ID parametro si riferisce a un'altra tabella che memorizza le intestazioni della colonna di input (200,00 202,50 205,00 ...).

... Non so abbastanza su come stai interagendo con i dati, ma sarei propenso a scegliere un'altra opzione: avere una tabella separata per ogni ID parametro e quindi, se necessario, avere una vista che unisci i vari parametri per data e posizione nella tabella più ampia (240 colonne); se era importante mantenere il DataID accessibile nella vista, è possibile utilizzare un UNIONanziché un JOIN, ma le colonne saranno scarsamente popolate.