Cita:
Empezado por Lepe
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.
|
Lepe, por algo dije al final de mi mensaje que haría falta más análisis
Siempre tuve en cuenta lo que dices, de hecho es natural (y hasta se podría decir que obvio) que implementar mi idea sería un poco más "lenta" y complicada que la mantener una estructura más simple.
Yo ofrecí un punto de vista que como muchas cosas tiene su lado bueno y su lado malo. Como bien dices, si se elije mi opción habrá que interpretar la información para conseguir las operaciones.
Firebird es rápido y puede soportar la cantidad de información. Eso lo se. Yo me pregunto: ¿Que tipos de consultas se harían?¿Que informes se confeccionarían?¿Que tan problable es que se recurra a una consulta que intervenga a todos los datos?
A lo que voy es que si en las consultas no se emplean demasiados registros, podría optarse por mi método... No creo que "interpretar" los registros haga tan lento un equipo... sobre todo si las computadoras son da vez más veloces.
¿Cúantas veces al día se lanzarán las consultas? Una, dos... ¿100?
Yo creería que se puede compensar la "perdida" de tiempo en la interpretación de valores, con la cantidad de registros.
¿Cúantos registros se ahorrarían en un día?¿En una semana?¿En un mes?¿En un año? ¡Muchísimos!
Como dije, y vuelvo a decir... se necesita de un buen análisis.
Saludos,