Delphius: te lo has currado de verdad.
Aunque personalmente no lo haría por varias razones:
- No son datos repetidos, de acuerdo, se repite la temperatura, pero es a horas distintas, en un primer análisis, se podría incluso considerar la hora y temperatura como clave primaria compuesta. Tampoco lo sería, ya que introducir datos relevantes como claves de la entidad relación pueden entorpecer la lógica del negocio. Si podría crearse un índice compuesto en la base de datos, ya que siempre accederemos a ambos campos, por lo que aceleramos las búsquedas.
- Dejando los datos como estaban inicialmente, podemos delegar en simples sqls la forma de hallar las medias (leasé funciones "avg" del SQL/Firebird, y otras muchas funciones estadísticas que ya están implementadas). Si optamos por tu uso extendido, tendremos que interpretar los datos (ponderar cada dato) antes de pasarlo a la función estadística.
- Si se necesitan listados, gráficas de barras que tanto gustan a los jefes [...], resulta muchísimo más fácil tirar de la Base de datos que tener que interpretar los datos.
- Saber la temperatura de una determinada fecha y hora, nos obligaría a interpretar los datos de nuevo (porque podría estar oculto en ese dif_min).
Firebird ya es un motor bastante eficiente y rápido, si hablásemos de paradox
, quizás justificaría el uso de abreviaturas.
Yo por mi parte añadiría un campo calculado de tipo TimeStamp, que se forme a partir de la fecha y de la hora. La razón muy simple, esta sql:
Código SQL
[-]
select * from temp where
fecha_completa between '01/01/2004 23:59:59.999' and '01/01/2005 23:59:59.999'
es más fácil de entender y más legible que:
Código SQL
[-]
select * from temp where
(fecha > '01/01/2004' and hora > '23:59:59.999') and
(fecha < '01/01/2005' and hora < '23:59:59.999')
sin contar con otra muchas variantes que intervengan en la búsqueda.
Por otro lado, podremos usar 2 parámetros en lugar de 4 para los sqls.
Además, siempre tendremos el campo fecha y campo hora por separado (para cuando sea necesario).
Saludos.