Base de datos enormes con firebird. ¿Cómo la estructuro?

[jachguate]

Confirmando lo ya mencionado por casimiro, cuándo hablé de Linux me refería específicamente al servidor de base de datos y no a la aplicación que le alimentará o que sacará información de él.

Sobre el tema iniciado por Delphius, comentar que, con lo que puedo entender de la aplicación de la que hablamos, me quedo con la opción de guardar todos y cada uno de los registros en la base de datos.

Por que razón: Los discos duros y la memoria son cada vez mas baratos, mientras que el tiempo que puede requerir en desarrollo de sistemas mantener y procesar datos no planos seguramente cada vez está mas caro..

Además, añadir esa complejidad al sistema, inevitablemente hará que sea mas difícil de mantener (mas fácil cagarla, en otras palabras) y mas lento el desarrollo de informes o nuevas características.

Para evitar desperdiciar tiempo innecesariamente en procesar tantos registros, he dado la idea al inicio de hacer procesos peroódicos que vayan resumiendo la información.

Por ejemplo, pensemos en la tabla de temperaturas, que tendrá esta estructura

temperatura
=================================
ID_Temperatura  bigint
ID_Sensor       integer
Hora            Timestamp
Temperatura     double precision

De esta podría derivarse las siguientes tablas:

temperatura_hora
=================================
ID_TemHora      bigint
ID_Sensor       integer
HoraInicio      TimeStamp
HoraFin         TimeStamp
Temp_Promedio   double precision
Temp_Min        double precision
Temp_Max        double precision
moda            double precision

temperatura_dia
=================================
ID_TemDia       bigint
ID_Sensor       integer
Fecha           Date
Temp_Promedio   double precision
Temp_Min        double precision
Temp_Max        double precision
moda            double precision

Estas se podrían ir llenando en el mismo proceso que carga la información a medida que se cuente con toda la necesaria (una hora completa) o un día completo, y obviamente pueden extenderse para agregar otras estadísticas.

Así, por ejemplo, saber la temperatura promedio de un año completo para un sensor particular, en lugar de tirar sobre una consulta que barra 525,600 registros, será solamente una que barra 365 (los que ya tienen información por día). Igualmente sencillo podría ser tener la temperatura promedio para la hora de 3 a 4PM de todo un año, pero seguiría siendo igual de sencillo escribir un query que nos devuelva la temperatura promedio para las 3:14 PM de todo el año.

Ya del análisis podrá determinarse si estas tablas son suficientes o si podrían crearse otras que vayan resumiendo información por otros criterios.

Desde mi punto de vista, este modelo nos permite tener lo mejor de ambos mundos.

Hasta luego.