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

[[duilioisola]]

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

ID IDSENSOR IDUBICACION TIPO FECHA_HORA       DATO
 1      1          1      T  01/01/2008 00:01 xxxx
 2      2          5      H  01/01/2008 00:01 xxxx
 3      1          1      T  01/01/2008 00:02 xxxx
 4      2          5      H  01/01/2008 00:02 xxxx
...

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

[Angel Fernández]

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.

[rastafarey]

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

[Angel Fernández]

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.

[jachguate]

Empezado por Angel Fernández

¿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.

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

Empezado por Angel Fernández

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?

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 ) tomando en cuenta solamente los positivos del bigint.

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

Hasta luego.

[[egostar]]

Empezado por jachguate

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 ) tomando en cuenta solamente los positivos del bigint.

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

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

Salud OS

[[Delphius]]

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,

[Angel Fernández]

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.