¿Cuál es una buena manera de almacenar una gran cantidad de columnas?

Tengo un problema para decidir cómo almacenar estos datos en mi base de datos. ¿Alguna sugerencia sobre la mejor manera de hacerlo? No sé mucho sobre bases de datos, podría agregar.

Tengo datos en formato así, pero en lugar de 4, el número de columnas es de aproximadamente 240, por lo que cada fecha tiene 240 valores únicos asociados:

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 

Además, las filas están asociadas con DataSites.

Mi primer pensamiento fue tener una tabla como esta: DataID (pk), DataSiteID, ParameterID, Date, Value, con un índice en DataSite, Parameter y Date. El ID de parámetro se refiere a otra tabla que almacena los encabezados de columna de entrada (200,00 202,50 205,00 ...).

Mi segundo pensamiento fue simplemente tener una tabla con las 240 columnas impares. He ideado algunas otras formas, pero también son bastante insatisfactorias.

El problema que tengo con mi primera solución (no es un problema tan grande, pero no me gusta), es que Date y DataSiteID se repetirán para los 240 valores en esa fila de entrada, por lo que usa bastante de espacio extra.

Habrá aproximadamente 40 gb de datos al año entrando (en el formato de texto anterior), y los datos se buscarán por DataSite, Parámetro y Fecha. La cantidad de datos que ingresan probablemente se cuadruplicará en un año más o menos.

Alguna buena idea? Gracias James

editar: se trata de datos de series temporales, siendo las columnas medidas en diferentes longitudes de onda. Los datos querrán ser analizados dentro de un rango relativamente estrecho de longitudes de onda. También podría haber longitudes de onda adicionales agregadas en algún momento en el futuro.

editar: Gracias por las respuestas chicos, realmente lo aprecio :) Creo que probablemente pueda encontrar tiempo para ejecutar algunos experimentos con 500 gb de datos de prueba. Volveré a publicar con cualquier conclusión;)

Podría presentar un caso de cualquier manera, pero si los datos se van a utilizar para el análisis y a menudo desea ver varias columnas de esos datos al mismo tiempo, vaya con la tabla ancha. Asegúrese de conocer los límites de cantidad de columnas y tamaño de fila de sus bases de datos. Asegúrese de obtener los tipos de datos correctos. Si muchas de las columnas son nulas, SQL Server le permite optimizar la tabla para eso. También podría considerar usar una solución NOSQL (No solo SQL) para el análisis de este tipo de datos.

Si estos datos van a ser menos para el análisis, es posible que desee normalizarlos como se indica en su pregunta.

Tuve una situación muy similar a la suya, 257 campos con 30-50 gb al año entrando. Terminé simplemente manteniéndolo simple, una larga mesa grande en SQL Server. Mis datos se consultaron bastante pero principalmente en la fecha y funcionaron bien.

Podría haber desglosado los datos en mandriles lógicos más pequeños (grupos de 50 o más), pero en este caso realmente no tenía mucha ventaja, así que me ahorré la molestia.

Si me sintiera elegante ahora, podría considerar una opción NoSQL que es más adecuada en teoría, pero con datos de misión crítica probar cosas nuevas no siempre es bueno para los nervios.

Entonces, para responder tardíamente mi propia pregunta (el proyecto nunca se llevó a cabo al final), cuando logré obtener algo de tiempo libre, llené una tabla de prueba con 500 gb de datos con la tabla organizada de la siguiente manera:

Mi primer pensamiento fue tener una tabla como esta: DataID (pk), DataSiteID, ParameterID, Date, Value, con un índice en DataSite, Parameter y Date. El ID de parámetro se refiere a otra tabla que almacena los encabezados de columna de entrada (200,00 202,50 205,00 ...).

La configuración de la base de datos fue la instalación estándar de PostgreSQL en una vieja máquina de doble núcleo con 3 gb de ram. Ejecuté alrededor de una docena de consultas diferentes simplemente seleccionando datos por DataSite Date y ParameterID, promediando datos durante un período de 1 hora, período de 1 día e insertando nuevos fragmentos de datos. De memoria, todas las consultas tardaron menos de un segundo en ejecutarse. Ciertamente fue mucho más rápido de lo que esperaba y bastante útil. Una cosa en la que no había pensado era que con la tabla indexada de esta manera, el archivo de índice también era de casi 500 gb, por lo que tener una tabla de 240 columnas de ancho sin duda ahorraría mucho espacio en disco.

En Postgres, resolvería elegantemente esto con un tipo de matriz o un varray en Oracle.

No sé si es útil para su problema, pero para las columnas no necesito hacer solicitudes directas (cols que nunca puse en mi condición WHERE), y que solo son informativas cuando quiero toda la información sobre algunos filas específicas, las combino en un campo de blog JSON formateado.

Probablemente tomaría la decisión final del diseño dependiendo de la distribución de los parámetros_id consultados. Es decir, si hay algunos parámetros_id que se consultan casi exclusivamente, pondría sus valores en una tabla activa y los valores restantes en otra tabla fría .

Otoh, si su distribución de consultas es más o menos uniforme, cargaría un conjunto de muestras que vale unos días en una tabla donde un registro mantiene todos los valores para ver cuál es la relación entre registros / bloques db (o si incluso hay un problema de encadenamiento de filas , que es probable). Dependiendo de eso, haría una nueva decisión de diseño.

Bueno, después de leerlo, probablemente haría ambos enfoques para una decisión en paralelo.

Estaba releyendo la pregunta: si tengo esta respuesta correcta, en cada registro que obtenga como entrada, se rastrearán diferentes valores (en función de ParameterID):

El ID de parámetro se refiere a otra tabla que almacena los encabezados de columna de entrada (200,00 202,50 205,00 ...).

... No sé lo suficiente sobre cómo está interactuando con los datos, pero me inclinaría por otra opción: tener una tabla separada para cada ID de parámetro y, si es necesario, tener una vista que une los diferentes parámetros por fecha y ubicación en la tabla más amplia (240 columnas); si era importante mantener el DataID accesible en la vista, entonces podría usar un en UNIONlugar de un JOIN, pero las columnas se rellenarán escasamente.