Saber número de registros distintos en una columna de una consulta.

[lbuelvas]

Un procedimiento almacenado creo que no soluciona tu problema.

Es posible, sin embargo, que tus consultas puedan mejorar si incorporas un indice sobre el campo fecha (en caso que no lo tengas).

Aunque puede definir una estrategia valida (a pesar de tener redundancia de datos) que consistiria en elaborar un trigger after insert (despues de insertar) sobre la tabla tablasensores que escriba a otra tabla llamada por ejemplo fechassensores, los campo de esta tabla pueden ser {fecha, sensor, contador}.

Entonces cada vez que ingrese un registro a la tabla tablasensores, busque en la tabla fechassensores si existe un registro con la fecha y numero de sensor, en caso de no existir crea el registro con los valores {fecha, sensor, 1}; en caso que ya exista un registro, simplemente le sumas uno al campo contador.

Defini el campo contador por si necesitas saber cuantas registros por fecha hay para cada sensor.

[lbuelvas]

Olvidaba comentar que luego hacer consultas en la fechassensores va a ser relativamente facil y por supuesto muchisimo mas rapido.

Logicamente el sacrificio que tendra el sistema es que sera mas lento la entrada debido a las verificaciones, faltaria saber que tan alto es el volumen de registros por unidad de tiempo (por ejemplo cuantos registros po minuto) entran a la base de datosa ver si esta estrategia pueda trabajar de manera eficiente.

[Angel Fernández]

Gracias por vuestra ayuda y comentarios.

Lo que comentas, Luis, me parece muy interesante, una buena idea. Sin embargo, con una base de datos ya implementada y en uso desde hace meses, en la que ya hay doce millones y pico de registros, me parece que ya es un poco tarde porque me obliga a reingresar todos los datos.

Es desde luego buena idea para llevarla a cabo con la base en blanco. Tomo nota para una futura base de datos.

Deduzco, por lo que me comentáis, que no se puede ni filtrar los datos, ni hacer una consulta sobre los resultados de otra consulta que eran las dos opciones que lanzé al principio. ¿Es esto correcto?

De ser así, y en este punto en el que ya tengo ese montón de datos, ¿qué me queda? Lanzar la segunda consulta que apuntaba en mi primera intervención y esperar ¿no?

Lo que me preguntas Luis, en la BD ingresa un dato cada minuto de un total de 62 sensores, de ahí la cantidad inmensa de datos a la que no daba crédito enecumene. Y esa cantidad es para medio año: aún nos queda ingresar el otro medio.

Debo decir, que a pesar de esa monstruosidad, Firebird la mueve con soltura y en ningún momento se nota ese peso. Detrás hay un buen trabajo en cuanto a índices, que me llevó bastante tiempo y muchas consultas a este foro. Si os interesa, podéis echar un ojo a este hilo:

http://www.clubdelphi.com/foros/showthread.php?t=53508

Gracias.

Un saludo.

[lbuelvas]

Bueno lo que planteas es un sistema en linea que recibe registros de 62 sensores donde cada uno envia informacion cada minuto.

En esas condiciones no tendrias problema con la solucion que te planteo, en ocasiones es bueno tener tablas resumen para evitar tareas que consumen demasiado tiempo al motor de bases de datos en dar respuesta.

Lo que puedes haceren realizar pruebas en una base de datos en blanco como lo estás comentando, cuando te funcionen implementas los triggers en tu base de datos en producción.

Para los datos antiguos, debes elaborar un procedimiento almacenado que reconstruya los registros de fechas que ya estén registradas en la base de datos.

La ejecución de ese procedimiento almacenado no te va a interferir con el trabajo de los triggers con los datos nuevos.

[lbuelvas]

Si colocas los metadatos de las tablas sobre las cuales necesitas la elaboración de los triggers y procedimientos almacenados, con mucho gusto puedo colaborarte y de paso te introduces en el manejo de procedimientos almacenados.

[[RONPABLO]]

Con respecto a los indices que te sugirieron los has puesto?? ya los tiene la base de datos?? una consulta en una tabla con indices y sin indices es realmente diferente y puede ser una solución muy buena

[Angel Fernández]

Muchas gracias Luis por tu ofrecimiento, muy amable. Lo que ocurre es que la tabla es propiedad de mi cliente que, aunque aún no me ha pagado, no estoy seguro de que le gustara la idea.

Puedo explicar un poco de qué va: Dado que se recoge un dato cada minuto esto supone una cantidad inmensa de datos. Se estudiaron varias posibilidades, tomar la media cada 5 minutos, cada 10, etc. pero al final se decidió tomar todos los datos y si luego sobraban mejor que si faltaban.

He creado unos índices para luego agrupar los datos cada hora por ejemplo. La tabla tiene una columna que le llamo HORA_INT y que convierte la fecha y hora en un formato integer tal que así:

Fecha: 01/01/2008 Hora: Entre 10:00 y 10:59 --> Columna HORA_INT= 2008010110
Fecha: 01/01/2008 Hora: Entre 11:00 y 11:59 --> Columna HORA_INT= 2008010111
etc.

Esta columna tiene un índice.

Con un campo calculado obtengo un dato "Rango de tiempo" que por ejemplo, HORA_INT=2008010110 lo convertiría en "De 10:00 a 10:59"
Con un proceso similar, tengo varios índices: DIA_INT, SEMANA_INT, 5MINUTOS_INT, ETC. Así, si quiero un dato cada día por ejemplo, agrupo los datos por días obteniendo la media, el máximo y el mínimo.

Fecha Rango de Tiempo Sensor Media Máximo Mínimo
-------------------------------------------------------------
01/01/2008 De 10:00 a 10:59 01 15.00 16.00 14.00
01/01/2008 De 11:00 a 11:59 01 16.00 16.00 14.00
01/01/2008 De 12:00 a 12:59 01 17.00 16.00 14.00
01/01/2008 De 13:00 a 13:59 01 18.00 16.00 14.00

etc.


Con estos índices obtengo algo que yo entiendo como "razonablemente rápido". Una consulta en un rango de fechas de 3 meses, para 31 sensores, agrupados por hora, tarda algo menos de 2 minutos y devuelve 40.000 registros con los que elaboro un gráfico. Mi ordenador es un amd a 3000, mononúcleo con 2,5 GB de ram con win xp sp2.

Para elaborar el gráfico me iría bien saber qué sensores no tienen ningún dato en el rango de fechas de la consulta.

En fín, espero haberme expresado bien.

Un saludo.