¿Cuál es la mejor manera de almacenar datos históricos en SQL Server 2005/2008?

Question

Mi ejemplo simplificado y artificial es el siguiente: -

Digamos que quiero medir y almacenar la temperatura (y otros valores) de todas las ciudades del mundo sobre una base diaria. Estoy buscando una manera óptima de almacenar los datos para que sea tan fácil obtener la temperatura actual en todas las ciudades, como es obtener toda la temperatura históricamente en una ciudad.

Es un problema bastante fácil de resolver, pero estoy buscando la mejor solución.

Las 2 opciones principales que se me ocurren son los siguientes: -

Opción 1 - La misma tabla almacena los registros actuales e históricos

almacenar todos los registros actuales y de archivo en la misma mesa.

decir

CREATE TABLE [dbo].[WeatherMeasurement](
    MeasurementID [int] Identity(1,1) NOT Null, 
    TownID [int] Not Null, 
    Temp [int] NOT Null, 
    Date [datetime] NOT Null, 
) 

Esto todo es simple, pero lo que sería la consulta más eficiente para obtener una lista de las ciudades y no la temperatura actual? ¿Esta escala una vez que la mesa tenga millones de filas? ¿Hay algo que ganar si tenemos algún tipo de bandera IsCurrent en la tabla?

Opción 2 - Guarde todos los registros de archivos en una tabla separada

Habría una tabla para almacenar las mediciones actuales en vivo en

CREATE TABLE [dbo].[WeatherMeasurement](
    MeasurementID [int] Identity(1,1) NOT Null, 
    TownID [int] Not Null, 
    Temp [int] NOT Null, 
    Date [datetime] NOT Null, 
) 

Y una tabla para almacenar la fecha histórica archivado (introducido por una desencadenar quizá)

CREATE TABLE [dbo].[WeatherMeasurementHistory](
    MeasurementID [int] Identity(1,1) NOT Null, 
    TownID [int] Not Null, 
    Temp [int] NOT Null, 
    Date [datetime] NOT Null, 
) 

Esto tiene las ventajas de mantener los principales datos actuales magra, y muy eficiente para consultar, a expensas de hacer el esquema más complejo e insertando datos más caros.

¿Cuál es la mejor opción? ¿Hay mejores opciones que no he mencionado?

NOTA: He simplificado el esquema para ayudar a enfocar mejor mi pregunta, pero supongo que habrá una gran cantidad de datos insertados cada día (100.000s de registros), y los datos son actuales durante un día. Los datos actuales tienen la misma probabilidad de ser consultados que los históricos.

Answer 1

DEPENDE de los patrones de uso de las aplicaciones ... Si los patrones de uso indican que los datos históricos se consultarán con más frecuencia que los valores actuales, colóquelos todos en una tabla ... Pero si las consultas históricas son la excepción, (o menos del 10% de las consultas), y el rendimiento de la consulta de valor actual más común sufrirá al poner todos los datos en una tabla, entonces tiene sentido separar esos datos en su propia tabla ...

Answer 2

Sugiero que sigan en la misma tabla ya que los datos históricos se consultan con la misma frecuencia. A menos que agregue muchas más columnas a la tabla.

Cuando el tamaño se convierte en un problema, puede dividirlo por década y tener un procedimiento almacenado para unir las filas solicitadas.

Answer 3

Otra alternativa podría ser ir a una tabla para todos los datos y tener una vista de la temperatura actual. Esto no ayudará al rendimiento, pero podría ayudar a la legibilidad/mantenibilidad.Incluso podría obtener una vista indizada para mejorar el rendimiento si tiene la versión apropiada de sql.

Answer 4

Mantendría los datos en una tabla a menos que tenga un sesgo muy serio para datos actuales (en uso) o datos de historial (en volumen). Un índice compuesto con DATE + TOWNID (en ese orden) eliminaría el problema de rendimiento en la mayoría de los casos (aunque es evidente que no tenemos los datos para estar seguros de esto en este momento).

Lo único que me gustaría preguntar es si alguien querrá datos de los datos actuales y del historial de una ciudad. Si es así, acaba de crear al menos una nueva vista para preocuparse y un posible problema de rendimiento en esa dirección.

Desafortunadamente, esta es una de esas cosas en las que es posible que necesite perfilar sus soluciones con datos del mundo real. Personalmente, he utilizado índices compuestos como los especificados anteriormente en muchos casos, y sin embargo, hay algunos casos extremos en los que he optado por dividir el historial en otra tabla. Bueno, en realidad, otro archivo de datos, porque el problema era que el historial era tan denso que creé un nuevo archivo de datos solo para evitar la hinchazón de todo el conjunto de archivos de datos primarios. Los problemas de rendimiento raramente se resuelven con la teoría.

Recomendaría leer los consejos de consulta para el uso del índice, y "cubrir los índices" para obtener más información acerca de los problemas de rendimiento.

Answer 5

Usaría una sola tabla con vistas de índice para proporcionarme la información más reciente. Los servidores SQL 2005 y 2008 están diseñados para almacenamiento de datos, por lo que deben preformarse bien bajo esta condición.

Si tiene un patrón de datos que requiere escribir a menudo en el archivo db, la mejor opción sería tener una tabla activa y una tabla de archivo que actualice por lotes en algún intervalo.

Answer 6

Su tabla es muy estrecha y probablemente funcionaría en una sola tabla indexada correctamente que nunca superaría la capacidad de SQL Server en un modelo OLTP tradicional normalizado, incluso para millones y millones de filas. Incluso con las ventajas del modelo de doble mesa se puede mitigar utilizando el particionado de tablas en SQL Server. Por lo tanto, no tiene mucho que recomendar sobre el modelo de tabla única. Este sería un escenario de estilo Inmon o "Enterprise Data Warehouse".

En escenarios mucho más grandes, transferiría los datos a un depósito de datos (modelado con un modelo dimensional al estilo Kimball) regularmente y simplemente purgaría los datos en vivo; en algunos escenarios simples como el suyo, podría haber efectivamente NO datos en tiempo real - todo va directamente al almacén. El modelo dimensional tiene muchas ventajas cuando se cortan datos de diferentes maneras y se almacenan grandes cantidades de datos con una variedad de dimensiones. Incluso en el escenario de almacenamiento de datos, a menudo las tablas de hechos se dividen por fecha.

Parece que sus datos no tienen esto (Ciudad y Fecha son sus únicas dimensiones explícitas), sin embargo, en la mayoría de los almacenes de datos, las dimensiones pueden copo de nieve o puede haber redundancia, por lo que habría otras dimensiones sobre el hecho en el momento de la carga en lugar de copo de nieve para una mayor eficiencia, como Estado, Código postal, WasItRaining, IsStationUrban (artificial).

Esto puede parecer una tontería, pero cuando empiezas a extraer los datos para obtener resultados en almacenes de datos, esto hace preguntas como - en un día con lluvia en entornos urbanos, ¿cuál fue la temperatura promedio en Maine? - Es un poco más fácil de conseguir sin unir un montón de tablas (es decir, no requiere mucha experiencia en su modelo normalizado y funciona muy rápido). Algo así como estadísticas inútiles en el béisbol, pero algunas parecen ser útiles.

Answer 7

Si almacena todo en una tabla, ¿cómo va a hacer una base de datos relacional?

Ejemplo:

Identificación del -------------- GUID ---- PK

record_id ------- GUID

cada vez se insertará un nuevo registro, el [id] cambiará pero [record_id] se mantendrá igual. Ahora, si tiene que vincularlo con la tabla de direcciones, ¿cómo lo hará?