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

La única cosa que me preguntaría es si alguien querrá datos de los datos actuales e históricos de una ciudad. Si es así, acaba de crear al menos una nueva vista para preocupación y posible problema de rendimiento en esa dirección.

Esta es desafortunadamente una de esas cosas en las que puede necesitar perfilar sus soluciones contra 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 para él solo para evitar la hinchazón de todo el conjunto de archivos de datos primarios. Los problemas de rendimiento rara vez se resuelven por la teoría.

Recomendaría leer las sugerencias de consulta para el uso de índices y "cubriendo índices" para obtener más información sobre problemas de rendimiento.

Su tabla es muy estrecha y probablemente funcionaría en una sola tabla correctamente indexada que nunca superaría la capacidad de SQL Server en un modelo OLTP normalizado tradicional, incluso para millones y millones de filas. Incluso con el modelo de tabla dual, las ventajas se pueden mitigar mediante el uso de particiones de tabla en SQL Server. Por lo tanto, no tiene mucho que recomendar sobre el modelo de mesa única. Este sería un escenario tipo Inmon o "Almacén de Datos empresariales".

En mucho más grande escenarios, transferiría los datos a un almacén de datos (modelado con un modelo dimensional al estilo de Kimball) de forma regular y simplemente purgaría los datos en vivo-en algunos escenarios simples como el suyo, podría efectivamente haber NO datos en vivo - todo va directamente al almacén. El modelo dimensional tiene muchas ventajas al cortar datos de diferentes maneras y almacenar un gran número de hechos con una variedad de dimensiones. Incluso en el escenario del almacén de datos, a menudo las tablas de hechos son dividido por fecha.

Puede parecer 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 almacenado 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 tonto, pero cuando comience a extraer los datos para obtener resultados en almacenes de datos, esto hace que hacer preguntas como-en un día con lluvia en entornos urbanos, ¿cuál fue la temperatura promedio en Maine? - solo que un poco más fácil de conseguir sin unirse a un montón de tablas (es decir, no requiere mucha experiencia en su modelo normalizado y se realiza muy rápidamente). Algo así como estadísticas inútiles en el béisbol, pero algunas aparentemente resultan útiles.

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

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

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

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

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

Si almacena todo en una tabla, cómo va a crear una base de datos relacional.

Ejemplo:

Id--------------GUID----PK

Record_id - - - - - - - GUID

Cada vez que se inserte un nuevo registro, [id] cambiará, pero [record_id] permanecerá igual. Ahora, si tienes que vincularlo con la tabla de direcciones ¿cómo vas a hacer eso?