Hola xinxan22:
Cita: Si hago un SELECT en esa tabla con 100.000 registros o con 36.000.000 el tiempo es diferente.
Efectivamente, puede haber diferencias en cuanto a los tiempos, pero hay que ver si esta diferencia es realmente significativa... la consulta tal como lo tienes en realidad no se puede optimizar mucho que digamos... podrías intentar utilizar la función BETWEEN en la condición de las fechas, pero en realidad no esperaría una variación significativa.
Aquí tendrías qué evaluar dos cosas:
1. ¿La diferencia de tiempos es realmente considerable? es decir, si estamos hablando de una diferencia de milésimas de segundos, o inclusive de algunos pocos segundos entonces es posible que la definición de los índices no sea la adecuada, para eso tendrías que hacer un SHOW CREATE TABLE para ver cómo los tienes definidos y de quizás plantear alguna otra alternativa distinta.
2. ¿Qué tanto impacto tiene en tus procesos esta variación en tiempos? es decir, cuál es tu costo/beneficio de esta variación.
Haciendo una analogía con el deporte, para un corredor de 100 metros planos una variación de una décima de segundo a la llegada a la meta con respecto al puntero puede implicar la pérdida de una medalla de oro. Sin embargo, para un ciclista de la Tour de Francia, perder en una carrera varios minutos con respecto a los punteros puede no afectar en absoluto el resultado de la carrera.
Lo mismo pasa con las BD's. Si los tiempos de ejecución de tus consultas afectan realmente el desarrollo de otras actividades, entonces podrías implementar algún tipo de técnica con tablas separadas, aunque la teoría de BD's te diga que no es lo mejor... Si en realidad la ejecución de las consultas no implica un riesgo en tus procesos, entonces has caso a la teoría y mantén tu información en una sola tabla.
En esto del diseño de BD no todo está escrito, no estamos hablando de una fórmula matemática o de una ciencia exacta... si bien soy de la misma opinión de gnzsoloyo acerca de que no es conveniente que tengas información en tablas separadas (que la teoría te diga que esta es una mala decisión), en la práctica puedes optar por alguna alternativa como estas...
Otro punto a considerar es también el tipo de consultas que vas a hacer... si la información que vas a consultar o comparar corresponde a más de un día, o de un año, si vas a comparar la información de varios días a la vez, con un sistema de tablas separadas tendrías que implementar estrategias como el uso de UNION's o JOIN's con lo cual podría a final de cuentas complicar de más la consulta, lo que terminaría por hacerlas más tardadas.
Si por el contrario las consultas son siempre referentes a un día en específico, a una semana en específico o a una año en específico e insistiendo en que tengas tiempos de respuesta realmente significativos, entonces si podrías pensar en una opción con tablas separadas.
Insisto, no hay una "mejor" forma de hacer las cosas... aquí tu función como DBA es evaluar todos estos escenarios y hacer un análisis de riesgos, costos y beneficios y elegir la "menos mala".
Saludos
Leo.