un compromiso (sql y orm bff)

[mauriciopasquier]

Bueno, después de darle todo el viernes al tema de preservar los valores de cero y escala históricamente, se me ocurre que podemos usar algo parecido al enfoque que ustedes armaron (lo de agregar las columnas zero y scale). Lo que sugiero es manejar la configuración como ahora, desde la aplicación, para actualizar los valores cero y escala, pero que cada vez que se registre un nuevo historical se calcule la concentración y se guarde ya calculada (con un trigger @fauno ?). Esto simplificaría y agilizaría las consultas, y el valor de la concentración es lo que nos interesa en el fondo, no la escala o el cero que haya habido configurado cuando se cargó el historical (de todas maneras esa información quedaría guardada en la tabla de parámetros que hice).

En resumen:

1. columna concentracion en la tabla historical
2. trigger que calcule la concentración con el value del nuevo registro y los cero y escala más nuevos de la tabla parametros para el grd_id del nuevo registro.
3. profit! Los backups y las consultas son directas

[gaspacho]

Y supongo que eso reduciria el costo de recursos y aumentaria la velocidad en la muestrade resultados. Hacer los calculos al vuelo cuesta mucho, generar un xls de mas de 2 dias tarda muchisimo, ademas que me come todos los recursos de la vps.

[fauno]

hice lo siguiente:

agregue los campos aparatos.cero_actual y aparatos.escala_actual

cree un trigger insert que setea el zero y scale de cada historical a los valores actuales segun el grd, luego calcula la concentracion y tambien la insert.

cree un trigger update que actualiza la concentracion (aunque los valores no se actualizan, pero fue lo primero que probe)

todo esto anda joya

[mauriciopasquier]

El cero actual y la escala actual ya estaban en la tabla parametros.

[fauno]

Queda deprecada B)

[gaspacho]

una explicacion para neofitos?

[fauno]

hay que correr el archivo sql/agregar_triggers.mysql como root de mysql. a partir de ahi cada registro calcula su propia concentracion. hay que cambiar los modelos y el admin para que usen las columnas nuevas.

[gaspacho]

es mucho eliminar el registro post calculo? y tener solo una tabla con los resultados? si no se puede, tener un boton "vaciar historical"? asi no tenemos doble info y economizamos espacio, entre los 2 aqm y los dos dusttrak vamos a tener muchos

[fauno]

no ocupa tanto lugar eh

[gaspacho]

ustedes son los doctores, yo por evitar situaciones futuras...

[mauriciopasquier]

aparatos es para guardar la información independiente del tiempo de cada aparato. Si sacás la tabla parametros no hay forma de tener la historia de los cambios en cero y escala. Si sólo interesan para el momento de calcular la concentración, bien. Si no, mal.

es mucho eliminar el registro post calculo? y tener solo una tabla con los resultados?

qué registro?

[gaspacho]

claro, entra un registro, el trigger se dispara, hace el calculo y lo almacena en otro lugar, que es donde finalemente se hace la consulta para mostrar el resultado, ese regsitro con los valores en crudo ya no importan, si lo que queremos ver y almacenar es el resultado.

ya teniendo los resultados en aparatos no me interesa la informacion pasada de historical

[mauriciopasquier]

Y las demás columnas? Nadie ni nada más usa esa tabla? Por mí mejor que no dependamos de esa

[gaspacho]

y las demas columnas ya no tendrian sentido, queda historical con las columnas originales, zero y scale queda como parametro en otro lado y no importa cuanto se cambien sus valores, ya tenemos uan tabla con los datos convertidos

[mauriciopasquier]

aparatos sólo guarda cosas de cada aparato, igual necesitamos una tabla para los valores medidos. Ahora es historical, que es la que ustedes llenan. Si usamos el trigger para llenar la nuestra (ponele mediciones o algo así), qué columnas tendrías además de grd, valor y concentración?

[gaspacho]

[gaspacho]

(no quiero implementar mpj, pero me gusta participar, asi tambien aprendo :) ) <- problema planteado en xkcd

[gaspacho]

me olvide, en los resultados ya no nos interesa tampoco mostrar ni escala ni cero ni valor, la tabla de resultados seria

id / fecha y hora / concentracion

[mauriciopasquier]

diseño! (no me acuerdo qué número de xkcd decís)

[fauno]

tiene que almacenarse en otro lugar? sobre lo de la concentración, se pueden eliminar las columnas zero y scale en historical y guardar sólo el resultado, pero me pareció que a la larga era mejor que puedan deshacer el cálculo, no? (por algo se llama historical :P)

[gaspacho]

vos decis dentro de la misma tabla historical, poner una columna concentracion?

[fauno]

claro es lo que hice con los triggers, pero me olvidé de comitearlo

[gaspacho]

no, no hay que deshacer el resultado, ademas el dispositivo que nvia los datos tine una logica independiente del dusttrak, a los operadores lo unico que deben (y quieren) saber es una hora y una concentracion. todo dato, como value, zero, bba bla bal no les importa ni quiren aprender para que sirve.

[fauno]

https://github.com/fauno/dusttrak/blob/feature/mysql-triggers/sql/agregar_triggers.mysql

[gaspacho]

add column escala_actual float, add column cero_actual integer;

no seria mejor algo como tener una tablita con con los parametros por id

si en el registro entrante id = x calcular con los parametros para x unbicados en 'parametros'

[fauno]

si también, pero si ya estás guardando el valor de cero y escala por cada registro para qué necesitarías una tercera tabla, aparte de historical y aparatos?

[mauriciopasquier]

no seria mejor algo como tener una tablita con con los parametros por id

Esto es lo que había, en parametros

si también, pero si ya estás guardando el valor de cero y escala por cada registro para qué necesitarías una tercera tabla, aparte de historical y aparatos?

No la necesitás, ni tampoco necesitás guardar zero y scale en historical, están al pedo si no se require cambiar el pasado. Lo que se necesitaba era preservar el pasado de los cambios en cero y escala, pero una vez que estamos calculando la concentración al insertar el historical, listo.

Resumiendo:

1. tabla mediciones con grd, concentracion, timestamp
2. tabla aparatos con grd, nombre, blabla, cero y escala
3. trigger que inserta en mediciones calculando la concentración con el value del nuevo registro y los cero y escala de la tabla àparatos para el grd_id del nuevo registro
4. después de esto, hagan lo que quieran con la tabla historical

[gaspacho]

+1 mpj

[mauriciopasquier]

bueno, sale así? mergeo tu rama @fauno ?

[fauno]

dale, vas a tener que modificar los triggers si los datos se insertan en otra tabla. no sería mejor que quede la concentración como un atributo del modelo Historical y listo? se simplificaría mucho el código me parece.

@gaspacho estás completamente seguro que el historial de cero y escala no es necesario?

[mauriciopasquier]

dale, vas a tener que modificar los triggers si los datos se insertan en otra tabla. no sería mejor que quede la concentración como un atributo del modelo Historical y listo? se simplificaría mucho el código me parece.

para mí simplifica hacernos independientes del esquema de otro. O sea, vamos a tener casi el mismo modelo "historical" (mejor llamado medición) pero basado en otra tabla, una nuestra.

@gaspacho estás completamente seguro que el historial de cero y escala no es necesario?

mientras no se borre nada de la tabla historical estamos a tiempo de arrepentirnos

[fauno]

ok, y historical queda monkeypatcheada con los triggers entonces.

[gaspacho]

si, el problema de agregar campos a historical es que quedamos de rehen de nuestra propia mod, teniendo una tabla independiente historical solo nos provee los datos, en definitiva lo unico que necesitamos

[gaspacho]

o sea, sale asi

[mauriciopasquier]

@gaspacho habías pedido avisar del error si historical.value era menor que el cero, guardemos el value en mediciones.valor para eso

[gaspacho]

o si el resultado es menor a 0

[mauriciopasquier]

si el value menor que 0 o si es menor que el mediciones.cero? o ambas? si es menor que 0 seguro que también es menor que mediciones.cero... /me no entiendou

[gaspacho]

no, si value es < a zero

el resultado da negativo, eso es malo, hay que resaltarlo

[gaspacho]

o en el campo concetracion que diga #ERROR por ejemplo

[gaspacho]

-0.02gr no existe, es materia negativa

[fauno]

che y el trigger hay que crearlo a mano entonceS?

[mauriciopasquier]

No, la verdad me olvidé de la migración. Se puede escribir en sql pero hay que cambiar el tipo del schema. O hacer una tarea, o agregarlo en db:seed.