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

Saludos al foro.
Quisiera ver si podéis orientarme según vuestra experiencia.
Tengo que crear una base de datos para almacenar muchísimos datos.
Se trata de recoger los datos que toman sensores de humedad, temperatura, lluvia y encharcamiento.
Estos datos se toman cada minuto a lo largo de las 24 del día todos los días del año y hay 30 sensores de humedad, otros tantos de lluvia y 2 ó 3 de lluvia y otro par de encharcamiento.
Total unos 70 sensores. Los datos los recoge un datalogger en formato csv (separados por puntos y comas), de ahí con una aplicación delphi los paso a una BD de Firebird.
Me he decidido por Firebird gracias a los buenos comentarios que he leído en este foro.
Ahora bien, haciendo cálculos así rápidos me salen aprox. 37 millones de entradas al año (24 horas x 60 minutos x 365 días x 70 sensores).

Estoy en la duda de hacer una tabla por sensor (sea de temperatura, humedad, etc no importa) del tipo:
Tabla: SENSORH1 (Sensor 1, tipo humedad)
Campos:
ID IDUBICACION FECHA HORA DATO
------------------------------------------------------------
1 2 14/01/2008 14:30:05 52.36
2 2 14/01/2008 14:31:00 52.46
ETC....

idubicacion enlazaría con otra tabla donde pondría datos de ubicación, etc.

Tabla2: SENSORT1 (Sensor 1 de temperatura)
Mismos campos

Y así hasta 70 tablas, una para cada sensor. Estas tablas almacenarían 1440 datos diarios (24 horas x 60 minutos).

Otra opción sería una tabla para humedad con los datos de todos los sensores de humedad, otra para temperatura, etc. con estos campos:

ID IDSENSOR FECHA HORA DATO
------------------------------------------------------------------
1 1 14/01/2008 14:30 xxx
2 2 14/01/2008 14:30 xxx
3 3 14/01/2008 14:30 xxx
etc.

idsensor enlazaría con otra tabla donde indicaría tipo de sensor, ubicación etc.

Así tendría 4 tablas (humedad, temp, lluvia y encharcamiento) con 100800 entradas diarias (24 x 60 x 70 sensores).

¿Qué opción os parece mejor para optimizar la base de datos? ¿Alguna otra alternativa? Y otra cosa: ¿Firebird puede con tantos registros? Hay que tener en cuenta que se desea crear un banco de datos de varios años (5 ó más). Para 7 años por ejemplo saldrían: (100800 x 365 x 7) = casi 256 millones de datos.

Agradeceré mucho vuestros comentarios, ya que hasta ahora he hecho muchas cosas en access, y muy pocas en firebird y con sólo algunos cientos de datos.

Utilizo Delphi 7, Firebird 2.0 y componentes MDO.

Gracias de antemano.

Una preunta importante que te debes hacer antes de seguir:
Se vana a hacer comparaciones/sumas/totales entre los sensores?

Si tienes todos los sensores en una tabla entones un selecto podría ser algo asi:

Código SQL [-]
Promedio de temperaturas de enero:
select avg(temperatura) from sensor 
where 
tipo = 'T' and 
fecha between '01/01/2008' and '01/31/2008 23:59:59'
/*y podrás acotar más la búsqueda si quieres*/

Si los tienes en diferentes tablas tendrás que hacer muchos select y sumarlos luego dentro de un procedimiento, por ejemplo.

Creo que lo mejor sería una sola tabla de esta manera

Nota: El campo tipo timestamp en Firebird puede tener la fecha y la hora juntas.

Con respecto a los límites, creo que ni siquiera con 100 años llegarías a tocarlos.

Mira este link

Saludos

Gracias duiliosola por tu rápida respuesta. Justo después de colgar el mensaje estaba pensando justamente esto que tú me comentas. Si tengo que hacer consultas entre los sensores, y éstos los tengo desperdigados por 70 tablas, tendré que hacer otros tantos select y luego juntarlos. Creo que tu respuesta viene en la línea de lo que había empezado a pensar: quizá sea mejor una sola tabla como tú me comentas.
Es un buen comienzo. Será cuestión de darle alguna vuelta más pero por ahí van los tiros.
En cuanto a los límites, me tranquiliza leer que no hay problema.
Gracias de nuevo.

Resp
 

Yo te reciomiendo que hagas un diagrama ER y esto te dara las tablas y la estructura que necesite.

Ejemplo de diagram ER (Solo un parte)
Esto es un diagram muy granular
ya que lso datos extras pordrian ser direfente
o unos tener mas o menos datos qu otro se maneja
se crea una aespecificacion la cual se manejaria
por medios de vistas
Los campo comunes a cada sensor iria en Sensores
las otras cuatros solo tendri alos datos concenniente
a ellas.

Si no me explique bien puedes leer ER.


Los Sensores Estan en una ubicacion
los sensores pueden ser De
humedad
temperatura
lluvia
encharcamiento

/\
---------n / \ n-----------
|Senores|-----/esta\-----|Ubicacion|
--------- \ / -----------
| \ /
| \/
------
|------\ES/-----------------------
| \/------------------------|
| | | |
| | | |
| | | |
| | | |
---------- ------------- ------ ----------------
|humedad| |temperatura| |lluvia| |encharcamiento|
---------- ------------- ------ ----------------

Aqui tendrias 7 tablas
======================

Sensores
--------
Id
....


Ubicacion
---------
Id
...

(Donde esta ubicado cada sensor)
R Sensores Ubicacion
--------------------
Id
IdSensor
IdUbicacion
...

(Les agrego la se para saber qu eson sensores)
S_humedad
----------
Id
IdSensor
...

S_temperatura
----------
Id
IdSensor
...

S_lluvia
----------
Id
IdSensor
...

S_encharcamiento
----------
Id
IdSensor
...

La cantidad e tablas dependera de tu diagram y cuantas cosa quieras
manejar

Gracias rastafarey por tu participación. En efecto, algo así es lo que va tomando forma en mi cabeza. ¿Podrías darme alguna referencia de dónde aprender algo más del sistema ER que me comentas? Si busco en google "ER" al ser tan corta la cadena me salen demasiadas cosas.
Una cosa que es una tontería pero que me escama; al tener tantos datos la tabla de humedad, el campo id (autoincremento y clave primaria) debe ser del tipo biginteger ¿no? Si va a almacenar cientos de millones de datos, smallint se queda corto ¿Integer también serviría?

Un saludo.

En vista del volumen de información, te recomiendo:

• Un servidor linux, en mi experiencia, el desempeño sobre exactamente el mismo hardware es bastante superior en linux que en windows, por no hablar de la estabilidad y la seguridad en general del sistema.
• Podes realizar procesos periódicos: nocturnos, semanales, mensuales, que procesen la información y la "mastiquen" para dejar tablas con resumenes tipo promedio, máximos, mínimos, de manera que las consultas y reportes que resumen información puedan hacerse sobre esas tablas, con lo que conseguirás una mejora MUY importante en el rendimiento de tu aplicación.
• Aprovecha los backups diferenciales que están disponibles ahora, dado el tamaño de la base de datos, eso también ayudará en el desempeño.

Justamente hace dos días alguien hablaba de bases de datos "enormes" en este hilo (en inglés). NO dudo que lo que allí se comente te sea de utilidad.

Hasta luego.

;)

ERM => Entity Relationship Model o Modelo Entidad Relación

Si tomamos la parte positiva del Integer, el límite teórico de la llave sería de 2,147,483,647 (dos mil ciento cuarenta y siete millones y pico de registros)

si hablamos de treinta y siete millones anuales que producirá tu aplicación, topará mas o menos en 58 años. Nunca se sabe cuánto tiempo estará corriendo un sistema, o si te aumenten el número de sensores. Yo usaría BigInt.

Con BigInt, podrías poner un sensor por kilometro cuadrado en el planeta, y aún así tendrías para una eternidad: 9,223,372,036,854,775,807 (nueve trillones doscientos veintitres mil trescientos setenta y dos billones, treinta y seis mil ochocientos cincuenta y cuatro millones setecientos setenta y cinco mil ochocientos siete registros) (quería escribir eso :D) tomando en cuenta solamente los positivos del bigint.

Te aseguro que ningún sistema de archivos actual soportará eso.. :D

Hasta luego.

;)

Me pregunto porque terminará en 7, será que hay algo que ver con ese número cabalistico :D:D:D

7 maravillas
7 nuevas maravillas
7 dias de la semana
7 dias de la creación
......:rolleyes::rolleyes:

Salud OS

Se que soy de la voz de la inexperiencia pero quería saber, si no le es molestia a Angel Fernández, ¿Que otra ventaja ven o consideran si se empleara una única tabla?

Yo soy, hasta el momento, de la idea de que la base de datos sea un reflejo del dominio. Y si me pongo a pensar, yo optaría por tener una tabla de cada cosa: una para humedad, etc. Al menos me suena más lógico asi.

No se como será la perfomance de Firebird para un nivel tan alto de registros si se mantiene una tabla, a mi todavia me cuesta caer en esa elección.

Si bien es como dicen, que tener más tablas hará más lenta las consultas, creo que las cosas mantendrán cierta coherencia y orden.

Por otro lado, me pregunto ¿Es necesario que sea cada minuto? ¿En épocas de pocas lluvias, aún seguirían manteniendo esa "velocidad"? A lo que voy es si bien se necesita de cierta precisión para hacer estos tipos de estudios , que sean cada 1 minuto es una exageración. Sobre todo si consideramos que en variadas época del año los niveles tienen a mantenerse en un rango y no variar en cuestiones de minutos, algo que a gran escala pierde sentido.

¡Y que decir si los niveles son constantes! Yo me pregunto... y que haces si llegas a tener algo como esto:
HORA DATO
00:00 xxx
00:01 xxx
00:02 xxx
...
00:40 xxy
00:41 xxy
...

¿Qué tan viable es tener minuto a minuto si las condiciones no cambian?
Ten en cuenta esto... puede ahorrarte muchos registros.

En fin no se dije algo tonto, pero a mi me resulta lógico.

Saludos,

Gracias a todos por vuestras respuestas.
En cuanto a lo que dice el maestro jachguate de montarlo en linux no puedo menos que decir ¡uff! ¡Más quisiera tener conocimientos para ello! La aplicación que me recoge los datos la voy a hacer en delphi 7 porque en la universidad que participa de este proyecto tienen una licencia. Estuve barajando otras posibilidades open source o freeware como Lazarus pero francamente y con todos mis respetos para este tipo de proyectos, lo veo aún a mucha distancia de D7. Yo tengo ya cierta experiencia en D7 (aunque como veis por mis mensajes sigo siendo un aprendiz) ¿En qué lenguaje lo tendría que hacer para linux? ¿Phyton, PHP, Java? En todos ellos partiría de cero y tendría que recorrer un gran camino para llegar hasta los conocimientos que ahora tengo en delphi.
Sin embargo, estoy totalmente de acuerdo en que en las universidades deberían utilizar y enseñar más sistemas abiertos y no corporativos (más linux y no tanto Office y Microsoft) porque al final le hacen a uno ser esclavo de pagar enormes licencias o la opción mas usada: piratear. Te pirateas Windows, Office, Autocad ... que es lo que enseñan en estas universidades (al menos lo que yo conozco).
Pero me estoy yendo de varas. Volviendo a mi aplicación y contestando un poco a delphius (gracias también por tu valiosa aportación) sí podría hacer una tabla para humedad y temperatura porque los datos que recogen estos sensores son muy parecidos (rango de 0 a 100 en humedad, de 0 a 400 en temperatura en ºK. En cambio el dato de lluvia y encharcamiento es boleano sí/no por lo que también podría ponerlos en otra tabla juntos. Una sola tabla para todo, podría ser, pero sería un poco raro. Quizá dos tablas: una para temperatura y humedad y otra para lluvia y encharcamiento. Pero entonces se me plantea una cosa. ¿Es mejor una sola tabla con cientos de millones de datos o varias tablas con decenas de millones de datos? Me refiero mejor en cuanto a velocidad.
En cuanto a por qué guardar un dato cada minuto, en realidad es lo que están haciendo ahora mismo y lo están guardando en ¡ficheros de excel! Con 34000 datos el fichero va cojo y lento de narices. Evidentemente estos datos no se pueden manejar, simplemente guardar para tener un histórico. La idea es hacer consultas por hora y día, de los que extraer conclusiones y resultados más abordables.
Me interesa mucho lo que comentas, jachguate, de backups diferenciales, porque obviamente el tema de copias de seguridad me preocupa bastante pero que espero abordar más adelante. Os preguntaré más cosas sobre la marcha si os parece bien.
Saludos para todos y gracias otra vez. Me estáis ayudando mucho.

Lo que te comenta jachguate sobre Linux, se refiere al servidor.
Haces el programa en Delphi y la base de datos, en lugar de ponerla en un Windows, lo pones en un Linux, sólo has de instalar Firebird.
La conexión es igual que en windows, ejemplo:

Gracias por la aclaración Casimiro. De todas formas, mi cliente será quien decida dónde colocar la base de datos y la aplicación. Pero así a ojo, dudo mucho que sepa nada de servidores ni linux. De hecho, la base de datos está pensada en principio para trabajar en local. Tú llegas con tu pendrive con los datos que has sacado del datalogger en formato CSV, lo conectas a tú pc donde tienes la base de datos en cuestión y la aplicación y ésta saca los datos y los pone en la BD de Firebird.

Sí que hemos pensado en un futuro, conectar el datalogger a un ordenador y éste a la red, para poder acceder a los datos a través de internet en vez de estar arriba y abajo con el pendrive. Pero ahora mismo nos faltan conocimientos para hacer esto. ¿Esto se hace por IP, como la cita que pones tú Casimiro? El tiempo dirá cómo lo hacemos, pero ahora mismo, una base de datos FB y una aplicación en delphi es un salto cualitativo importantísimo teniendo en cuenta que el sistema actual de guardar datos es Excel. Somos ingenieros (no informáticos ni de sistemas) y a mí me apasiona este mundo de la programación pero me quedo en aficionado. Espero que con tiempo y vuestra ayuda ir aprendiendo;)

Un saludo.

Angel Fernández, por el tema Linux no puedo opinar, hay mentes entrenadas y sabias en el tema... yo quisiera exponer un poco de mi punto de vista.

Disculpa que lo diga, pero me resulta un poco de desperdicio estar ingresando información que es redundante. A lo que voy es que puedes implementar una regla del tipo:

Código Delphi [-]
If Dato.Humedad <> DatoAnterior.Humedad
   then begin 
            grabar(Dato.Humedad);
            DatoAnterior.Humedad = Dato.Humedad;
          end;

La explicación es simple: se compara el dato leído con el anterior (puede estar en una variable) y si son distintos guardarlos. El truco está entonces en que tu tabla guardará siempre y cuando se ha detectado un cambio (que no sea la hora claro está). Con esto consigues algo por el estilo:

HORA DATO
00:00 xxx
00:40 xxy

¿Que significa esto? que durante 40 min no se han detectado cambios.

Podrías diseñar tu sistema de manera que al migrar chequee las fechas y haga un análisis de los repetidos y te evitas la redundancia.
Es lo mismo tener esto:

00:00 xxx
...
00:39 xxx
00:40 xxy

Que tener esto:
00:00 xxx
00:40 xxy

¿Donde está el truco? En que se debe hacer una simple resta entre las horas para dectar los tiempos en que los datos han variado. Si se necesita saber los tiempos, dejaselo que te lo calcule, si fácilmente esa información puede ser "recuperada" a partir de otra. No se si me entiende...

La matemática es muy simple, y exacta.

Veamos con un ejemplo: supongamos que deseamos obtener el promedio de la temperatura de los primeros 6 minutos del día:
00:00 10
00:01 15
00:02 15
00:03 20
00:04 17
00:05 18
00:06 15

Promedio: (10+15+15+20+17+18+15)/6 = 18,33

Con la versión simplificada:
HORA DATO DIF_MIN
00:00 10 1 // la diferencia de min con el día anterior...
00:01 15 1
00:03 20 2 // 3-1
00:04 17 1
00:05 18 1
00:06 15 1

Promedio: (10x1+15x2+...+15x1)/6 = 18,33

Puede que te resulte complicado entenderme, pero si te fijas bien, el modelo "extendido" puede convivir con la versión "simplificada" si llevas ese campo DIF_MIN,

00:00 10 1
00:01 15 1
00:02 15 1
...
00:06 15 1

Y la matemática sigue cumpliendose... En teoría, no habría problemas en hacer convivir tus datos viejos con los nuevos (si es eso lo que te puede asustar). Por lo que las estadísticas y las operaciones que hagas no se verían afectadas por los repetidos.

Ahora tal vez tu me dirás, que deberá chequearse en la base de datos siempre el último valor... pero eso no es cierto, si no entendí mal nada impide que nos quedemos en alguna variable con los últimos datos cargados y allí mismo compararlos y hacer la carga de ser necesario. Y es en esta etapa cuando podemos hacer el cálculo de las diferencias, ya que contamos con dicha información.

Con esto te evitas tener que consultar la base de datos minuto a minuto y no haces lento al servidor al pedir que te haga esos cálculos de diferencia de minutos.

Realmente espero que se entienda mi idea.

Cuando se desee armar una consulta, se pueden hacer los ajustes para que los muestre como si siguieran trabajando con excel (si deseas), el truco aquí es trabajr gracias a ese dichoso campo DIF_MIN. Independientemente si se trata de una o 5 tablas, este esquema funciona.

Igualmente sigue haciendo falta análisis en el tema, pero creo que la idea está.

Saludos,

Muchas gracias Delphius por tu dedicación a mi problema. Lo que propones es... muy bueno. Eres un tío grande.
Déjame que lo piense. Me has pillado recién comido y la cabeza la tengo un poco espesita.
Un saludo.

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.

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,

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.. :D

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

De esta podría derivarse las siguientes tablas:
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.

;)

Juan Antonio, me saco el sombrero!

Me dejaste callado, sin palabras. Habló la experiencia.

Cuando leí en tu anterior mensaje sobre esto no lo había comprendido del todo. No se en que tenía la cabeza que ni siquiera se me cruzó por preguntartelo. Ahora lo entiendo.

¡Simplemente genial!

Bueno... si me quedan algunas dudas... más que nada por curioso:D:
El "cálculo" de las Temp_Min, Temp_Max, Tem_Promedio. las realizarías una vez finalidado el ejercicio? O directamente con algún Tigger After Insert de la tabla Temperatura?

Tu hablas de las dos opciones, pero en base a tu experiencia... ¿Cuál optarías? Se que en parte esto depende de las necesidades, del negocio, etc... ¿pero cual eligirías en esta ocasión?

Saludos,

¿double precision jachguate? ... yo es que le tengo manía a ese tipo de dato, prefiero los numeric(10,2) por aquello de no perder precisión y poder encontrar una temperatura exacta.

Saludos

Yo siempre uso double precision :)

Siempre depende.... para no sobrecargar con disparar un trigger tantas veces, podría ser la aplicación la que, cada vez que detecte un cambio de hora, dispare un stored procedure que valide aquellas horas que no se han procesado y realice el cálculo, o podría ser otra aplicación diseñada específicamente para realizar esta tarea. En este tipo de situaciones... firebird aún carece de maquinaria mas pesada. En Oracle, por ejemplo, podes definir una "tarea", que la propia base de datos dispara en base a un calendario... es como un timer, pero dentro de la propia BD... simplemente fantástico.

Aún no lo se... pero si tuviera que tomar una decisión ahora mismo, con la información que tengo, lo haría en la aplicación que carga los datos por una razón: menos tiempo de desarrollo

Lo dije sin pensarlo mucho, tomando en cuenta que, bueno, son temperaturas... no monedas. Para encontrar temperaturas exactas, siempre queda el recurso de redondear, moldear como numeric o hacer un between entre un rango de "tolerancia" para la precisión (¡que exactitud!)

Hasta luego.

;)

Está claro que Casimiro se guarda algún "as" debajo de la manga.

En cuanto al error de precisión, no es que lo diga yo, sino los creadores de interbase en la documentación.

Quizás hace unos años estaba justificado el uso de double precision (porque ocupan menos bytes en la BD al almacenarlo), y puede que en casos como este, donde se guardarán muchísimos valores, haya que tenerlo en cuenta. Me pareció oportuno comentarlo, aunque no quiero "desvirtualizar" el hilo (¿verdad AzidRain?).

Sabido el detalle, podemos continuar con el tema original ;).

Saludos

Mi idea ahora mismo es la siguiente, componiendo en mi cabeza todo lo que me estáis diciendo:

Tabla Humedad y Temperatura
---------------------------
Dado que el tipo de dato que almacenan es parecido (rango 0-100 y 0-400 respectivamente) y los datos de H y T se estudian conjuntamente, los junto los dos en una sola tabla.
Campos
ID (bigint como me dice jachguate) IDPROYECTO (smallint) IDSENSOR (integer) FECHA (date) HORA (time) FECHAYHORA(timestamp según apunta Lepe) DATO (smallint)

IDPROYECTO enlazará con una tabla donde se indique descripción del proyecto y otros datos
IDSENSOR enlazará con la tabla de sensores

Tabla sensores
--------------
IDSENSOR TIPO(HUM, TEM, LLU, ENC) UBICACION

Tabla Lluvia y Encharcamiento
------------------------------
Por el mismo motivo junto lluvia y encharcamiento.
Campos:
ID IDPROYECTO IDSENSOR FECHA HORA FECHAYHORA DATO(true/false)

El tipo de consulta que quiero realizar, al menos para temperatura y humedad, es datos agrupados por hora para realizar gráficas. En código sql (más o menos, lo escribo de cabeza)

Código SQL [-]
select idsensor, extract(year from FECHAYHORA) as anyo, extract(month from FECHAYHORA) as mes,
extract(day from FECHAYHORA) as dia, extract(hour from FECHAYHORA) as hora,  count(DATO) as cont, min(DATO) as Minimo, max(DATO) as Maximo,
avg(DATO) as Media
from tabla1
group by idsensor, anyo, mes, dia, hora
order by idsensor, anyo, mes, dia, hora

En cambio lo de lluvia y encharcamiento no sé muy bien qué quiere el cliente (será objeto de un próximo encuentro) pero lo que comentaba Delphius me ha hecho pensar mucho. Aquí en Valencia (España) donde yo vivo, podemos tirarnos meses sin llover. ¿Para qué guardar un dato de lluvia cada minuto que sea false, false, false,... durante meses? Y lo mismo para encharcamiento.

Tendremos que definir qué queremos hacer con esos datos (quizá una consulta por mes sea suficiente) o tal vez sea para activar alguna alarma si hay encharcamiento. En este último caso, un dato cada 10 minutos como mucho sea suficiente.

De lo que me comentáis me surgen algunas dudas. ¿Las consultas las puedo hacer cada vez que las necesite o mejor guardarlas en tablas como me dice jachguate? ¿Si tengo un campo FECHAYHORA (timestamp), necesito también FECHA (date) y HORA (time), como dice Lepe, para hacer mejor las consultas por SQL?

Gracias a todos por vuestra dedicación.

Saludos.

Muy linda la teoria, pero la practica es superior.

Lo mejor que puedes hacer es crear una BD, y llenarla con la cantidad de registros presupuestada, y ver que tal anda.

Ademas, el diseño es poco optimo para la lectura, como dicen la gente de digg "Datos normalizados son para niñitas" (http://www.niallkennedy.com/blog/uploads/flickr_php.pdf - el termino real es mas ofensivo!-).

Cuando se tiene un conjunto masivo de informacion y se quiere optimizar la lectura se debe hacer todo lo inverso a la logica normal:Se desnormalizan los datos.

Eso es lo que se hace para los sistemas OLAP. El ejemplo tipico es la fecha. En ves de ingresar un datetime se hace:

Fecha, Año, Mes, Dia, Hora, Min, Sec

Todo separado. Eso es genial porque puedes indexar de forma MUY eficiente.

Tambien en la medida de lo posible se precalcula todo. Por ejemplo, en este foro para sacar el numero de post, en vez de hacer un SELECT COUNT(.... se hace un campo contador en la table padre y se aumenta y decrementa de acuerdo a las repuestas del thread.

Para hacer bases de datos muy enormes, y se optimiza la lectura:

- Se separan las tablas
- Se separan los archivos de la BD enh diferentes discos. Para cosas realmente inmensas se separan en discos de red, pero este no es el caso ;)
- Los archivos de indices se ponen en discos aparte de los de datos
- Se desnormalizan los datos y se precalculan las sumas y los conteos
- Se arman vistas, y si el motor lo soporta, se indexan.

Eso es a grandes rasgos. Pero como digo, lo mejor es que metas datos de prueba y mires antes de ir por este o aquel camino.

Hola a todos,
interesante el hilo.
Bajo mi punto de vista, mamcx lleva razones de bastante peso en su planteamiento. Cuando se preparan bbdds de semejante tamaño, lo más importante es tunear la bbdd, para que el rendimiento sea óptimo.
Las aportaciones de todos los participantes me han parecido MUY BUENAS, pero además de todo eso, que es importante, lo es tanto o más el tema de la configuración de la bbdd y del propio srv.
A saber, discos scsi de alta velocidad, tablas en unos discos, indices en otros, nº de indices exactos tras el estudio del rendimiento, tamaño de la página exacto, ...

Bueno, la particularidad del sistema, la particularidad del presupuesto, y la particularidad de los conocimientos de quien lo desarrolla, también influye ( y mucho ), aunque más vale tener todo en cuenta para luego no llevarse sorpresas.

Saludos a todos

Eso me viene muy bien saberlo, porque los datos que yo recibo en formato texto, vienen así, el año por un lado, el mes por otro, el día por otro, etc.

Como voy a agrupar frecuentemente por hora y presumo que también por mes, puedo crear una columna HORA_STR tipo CHAR(10) cuyo dato sea tal que así:

2008011508 (Año 2008, mes 01, día 15, hora 08) y ponerle un índice.

Y otra MES_STR tipo CHAR(6) con datos:

200801 (año 2008, mes 01) y ponerle otro índice.

De esta forma, al agrupar por hora no tengo que hacer un extract(hour from fecha) sino sencillamente agrupar por el campo HORA_STR.

¿Os parece buena idea o es una tontería?

Lo que dice fjcg02 me acongoja un poco... mis conocimientos son bastante pobres.:(

Un saludo.

No quería acongojar a nadie. Simplemente recordar que a veces el rendimiento de una bbdd no depende únicamente del análisis y el desarrollo, sino de algo que a veces se nos escapa, que es la configuración del srv de bbdd y la propia bbdd. Yo nunca he tenido que llegar a estos extremos porque nunca he tenido bbdd's tan grandes, pero en ocasiones - sobre todo cuando manejas volumenes tan grandes - es la solución a esos problemas de rendimiento.
Además, soy el primero que utiliza firebird - y cualquier otro motor - según se instala, sin cambiar nada.

Saludos

Era broma.
 

Lo que dije, fcjg02, supongo habrás entendido que era broma. Por supuesto que cualquier aportación será bien recibida, incluso si es un tirón de orejas.

Saludos.

Es mejor dejar el año, mes, dia en columnas separadas que meterlas en un solo campo. La razon es que en vez de tener un solo indice tenes 3>, se hace muy optimo las consultas y es mas flexible porque tampoco tienes que hacer substring (por ejemplo, para llegar al dia) y ademas los campos se pueden dejar tipo INTEGER que es mas optimo que tipo STRING.

Por lo demas, tampoco es de enredarse mucho la pita. Hay un principio (el de Paretto) que dice que el 80% del esfuerzo se concentra en el 20% de las cosas. Determina que es lo mas probable y optimiza para ello, pero no te pongas a complicarte (igual, la optimizacion prematura causa mas lios que lo que mejora).

En terminos generales, tunear la BD, tener suficiente RAM y si se puede contar con discos en RAID o al menos 2 separados (1 para el OS otro para la BD) es mas que suficiente en la mayoria de los casos.

Personalmente creo que es una buena idea, de hecho si estuviera en tu situacion la consideraria seriamente

Ahora bien respecto del volumen de datos, y ya que se planteo por ahi el crear una tabla por cada sensor, por que no crear una tabla por año??, serian un numero de registros conocidos 565000 aprox y para el primer intento se podrian poblar con datos ficticios, hacer un par de consultas, y ver que como responde la aplicacion y el servidor

Definitivamente le recomendaria al cliente linux como sistema operativo, tanto por costo como por estabilidad (estoy desarrollando una aplicacion para windows que usa una base de datos Mysql en linux y al hacer las pruebas el rendimiento es bastante bueno, casi pareciera que estuviese local, la base esta en un servidor HP SCSI)

Gracias Tocomi por tu opinión. De hecho la base ya la tengo estructurada (con posibilidad de hacerle cambios) y estoy buscando formas de meterle los datos desde ficheros CSV. Lo de estructurarla por años, no me parece mala idea, pero me he enterado que el proyecto va a durar 5 años de recogida de datos y con esta cantidad de datos, firebird los aguanta perfectamente según he leído en la documentación que me han recomendado en este hilo.

Sí que he añadido los índices para anyo, mes, día y hora, los he puesto tipo integer como me recomendaba mamcx. Y también como me recomendaba mamcx, he decidido no "enredarme mucho la pita". He decidido un diseño de acuerdo a lo que me habéis indicado y lo he puesto en marcha.

Ya os iré diciendo qué tal va...

En ese caso, te recomiendo que leas, en mi blog, la entrada Exportar Datos de Firebird, que habla de como exportar/importar datos desde un csv de manera sencilla a firebird.

Siempre son bienvenidas las historias de éxito sobre firebird... :)

Un saludo

;)

Respecto al tamaño de la base de datos, me gustaría comentar algo que me ha pasado hoy atendiendo a un cliente que hacía tiempo no tenía noticias de él, la conversación fue más o menos así:
Pues eso, tenemos clientes, la mayoría, que sus bases de datos ocupan varios gigas, pero es el primero del que tengo noticias que pasa los 10 Gbs... y sin problemas.

Gracias Juan Antonio por tu sugerencia. Sin embargo, he visitado la entrada de tu blog y, si mal no he entendido, allí tratas el tema de exportar de Firebird a csv. Yo ahora mismo lo que pretendo es justamente lo contrario, importar de csv a delphi. Tengo los datos en un fichero csv separados por punto y coma y quiero leerlos y ponerlos en una tabla de firebird.

En la entrada dices que la importación lo dejas para una próxima entrada, la cual estoy ya impaciente por leerla. Lo que voy a intentar hacer es un readln de cada línea del fichero csv, después con la utilidad strman.pas (completísima unidad con infinidad de utilidades para trabajar con cadenas de texto -en torry está-) le voy quitando lo que hay delante de cada ; y lo asigno al campo correspondiente.

De tu blog me he descargado la hoja de trucos para Firebird. Interesante, pero echo de menos funciones estadísticas (min, max, avg, etc)

Una cosa, he intentado añadir tu blog a Google Reader y no he encontrado la sindicación de RSS. ¿No la encuentro o no existe?

En cuanto a lo que comenta Casimiro, me alegra saber que hay gente con bases de firebird muy muy grandes sin problemas.

Un saludo a todos.

Te dejo esto por si te sirve


Esta funcion lee la linea de texto y te devuelve la columna que le indicas, obviamente las columnas estan separadas por un punto y coma, lo tuve que hacer porque habia un cliente que enviaba los datos en formato CSV, y tenia que separarlos para poder incorporarlos a la base

En terminos practicos haces el readln, lo dejas en una variable string, por ejemplo "linea" y para buascar la quinta columna la sintaxis seria:

Buscandocol(linea,5);

Te devolveria lo que esta en la quinta columna, en formato String

Nos cuentas como te va

esas funciones las tiene FIrebird


una duda viendo la herramienta para exportar/importar... yo puedo crear/usar un archivo de texto que tenga el siguiente formato:

en vez de:

Gracias Tocomi por compartir tu código. Voy a probar a ver qué tal.

Da gusto con gente como vosotros.:p

Cierto que trato solamente el tema de la exportación, por ahora, sin embargo te queda el utilitario, al que basta ver la ayuda para figurarse cómo sería la importación.



Efectivamente.... yo también estoy impaciente por escribirla.. :D

Claro que si!

http://jachguate.wordpress.com/feed/
http://jachguate.wordpress.com/comments/feed/

Está en la sección meta.... pero ahora que lo mencionas, quizás no esté lo suficientemente visible o bien identificada... me daré a la tarea de ponerla mas visible en cuanto me sea posible.

Hasta luego.

;)

De nada, yo tambien he sacado ideas de aqui, asi que me parecio bien hacer un pequeño aporte de vuelta

Resp
 

Yo uso un libro. De base de datos ahorita no estoy en la casa asi que no recuerdo el nombre. Pero puedes buscar en google digrama de entidad relacion o diñeno de diagramas ER.

Ahora te doy una idea de como se te van dando las cosas.

1._ Ver que es lo que necesitas.
2._ Diseño del sistema.
3._ Diagrama de procesos.
4._ Diagrama ER.
5._ Llevar el diagramas ER a tablas.
6._ Escojer el SGBD que mejor se ajuste a tus necesidades(firebird es perfecto).
7._ Preparar el manejo de la data ya sea usando disparadores vistas u otras
cosas que te permita hacer el manejar.
8._ Lenguaje de programacion.
9.- Echar codigo.

Una cosa que te recomiendo encarecidamente es que hagas todo le trabajo de la base de datos en la base de datos y no le dejes el trabajo al lenguaje de programacion.

Sacale el maximo provecho al manejador de base de datos no lo uses solo para saca y meter consultar datos. Usa la integridad refencial has tus respectivas validaciones en la bd no importa qu etambien debas ahcerla antes de que los datos se envien al servidor. Si sigues estas reglas no tenf¡dras grandes complicaciones.

Lo que te digo es con conocimiento de cuasa ya qe ahorita estamos haciendo un sistema que tiene 329 tablas. y aun faltas como 60 mas. Donde el diseño de los procesos nos tomo casi 1 año.