Estructura Base de Datos

[mjjj]

Hola amigos... estoy en la etapa de definir la estructura de mi base de datos.... aer si me pueden aconsejar que camino seguir...

Tengo que almacenar informacion de 10 maquinas distintas... la informacion que voy a guardar es la siguiente: dia, hora, temperatura y presion, es decir que temperatura y presion tenia cierta maquina a la hora y dia señalado.

habia pensado en generar una base de datos llamada "2008", que corresponde al año 2008, dentro de de ella una tabla para cada maquina, es decir M1, M2, etc.

ahora bien cada tabla deberia contener aproximadamente 200.000 registro lo que deberia pesar mas o menos unos 30 MB, en conclusion todo la informacion de un año estaria pesando aproximadamente unos 300 MB.

Preguntas:
Es esta una buena eleccion de estructura de base de datos?
Seria mejor generar una base de datos general, en donde existen tablas para cada maquina, sin importar el año, es decir que la base de datos va a crecer indefinidamente al pasar los años.


300 MB, que corresponde a 10 Tablas de unos 200.000 registros cada una, es una base de datos muy grande.... Firebird es capaz de manejarla?

Espero haber podido ser claro en mi exposicion del problema... espero me puedan aconsejar... gracias

[Casimiro Notevi]

En cuanto a lo del tamaño, te paso un enlace que habla un poco sobre el tema: este

[jhonny]

No puedo meterme en la manera como diseñes tu programa, pero creo que deberias pensar en ¿Que pasaria si el dia de mañana deciden mas maquinas?, segun lo que he leido y la experiencia que he tenido con FireBird, no habra problema de almacenamiento, ya que por cada tabla tienes la posibilidad de trabajar hasta 30GB en la Versión 1.5 y mas de 30GB en la versión 2.0.1.

Pero si tienes una tabla para cada maquina ¿Que pasaria si tuvieras que agregar una maquina nueva?, pues tendrias que agregar otra tabla y en la programación deberias hacer mas cosas para tener en cuenta ese tipo de cambios, tu sabras como haces tus cosas, pero me pareceria mas sencillo de manejar todo en una sola tabla y simplemente con otro campo mas llamado Codigo_Maquina (Que haga referencia a otra tabla que contenga los codigos de las maquinas) y un contador autoincremental que sea la llave primaria de dicha tabla, pero esto ultimo solo es mi opinion .

Veo que se me a adelantado Casimiro por varios minutos .

[mjjj]

Tienes mucha razon con respecto a la incorporacion de una nueva maquina, y ademas me es mas facil para conectarme, no tengo que estar cambiando de tabla cada vez que necesite preguntar o guardar algo.

Por otro lado, si creo una sola tabla a la cual le voy a llamar REGISTROS, y donde voy almacenar toda la informacion de las 10 maquinas... aproximadamente voy a tener unos 2 millones de registros anuales... No sera mucho? ... que pasara despues de 3 años??

No sera mejor crear una tabla por año??

Ahora bien, el tipo de consultas que se podran hacer sobre la tabla son pr ejemplo:

Temperatura y Presion de cierta maquina entre Agosto y Septiembre del 2007.

O preguntar directamente por cierta condicion que no me deberia generar una respest de mas de 50.000 registros.

A donde quiero llegar con esto, si bien la tabla va a tener unos 2 millones de registros por año, cuando se haga cierta consulta nunca se va a tener mas de 50.000 registros como respuesta... que tan rapida puede llegar a ser esta respuesta??

La verdad es que hago estas preguntas porque no tengo ninguna experiencia con ningun tipo de tablas, por lo que no quiero equivocarme al realizar la eleccion.

La pregunta final: Que es mas aconsejable, tener una sola tabla donde se guarden todos los datos año tras año (2 millones de registros por año), o tener una tabla por cada año, lo cual es mas complicado a la hora de buscar alguna informacion porque voy a tener que seleccionar en el año (tabla) que deseo buscar.

Si la respuesta es la primera opcion (que creo que lo voy hacer de esa manera)... firebird podra manejar esa cantidad de registros??

espero no haber sido tan latero.. pero necesito despejar estas incognitas antes de seguir trabajando

muchas gracias por su tiempo

[Onti]

como dicen los compañeros , Firebird maneja bien tablas con millones de registros, personalmente he trabajado con con algunas bds de 2 gb sin mayores dificultades.

pero no hay mejor que tu hagas tus propias pruebas y te generes una bd de datos de prueba con una pequeña rutina insertes a tu tabla la cantidad de registros que quieres y sobre ella hagas la pruebas y evalúes el desempeño

Porque cambien se debe tomar en cuenta los indices de la BD, para realizar las consultas.

y también así ves como responde tu equipo.

[tefots]

lo normal seria crear una tabla , de maestro de máquinas
y otra de historico donde almacenaras , fecha , idmaquina , temperatura ,presion, etc.

tambien puedes crear una tabla por máquina.

O tambien puedes crear una unica tabla , donde almacenes fecha , y temperaturas de cada máquina , (simpre que almacenes la info de todas las máquinas a la vez claro).

todo depende de lo que luego en consultas o informes desees obtener se te haran mas o menos complicadas.

lo que debes hacer para comprobar el rendimiento , es tomar varias opciones como las que te he comentado , y haces un pequeño programita que inserte al menos trenta o cuarenta millones de registros.

si luego vas ha hacer consultas por fecha , deberás crear un indice secundiario por fecha , o por máquina todo depende.

no obstante , si no vas a hacer querys complicados , solo filtros de una tabla , no deberia haber ningun problema de rendimiento con tales cantidades de registros.


saludos

[Neftali [Germán.Estévez]]

Empezado por mjjj

Es esta una buena eleccion de estructura de base de datos?
Seria mejor generar una base de datos general, en donde existen tablas para cada maquina, sin importar el año, es decir que la base de datos va a crecer indefinidamente al pasar los años.

Creo que no es buena elección modificar el diseño de la Base de Datos dependiendo de si se van a generar más o menos registros o del peso de la Base de Datos.
Piensa que las máquinas cambian, los discos también para almacenar más cosas, incluso puedes cambiar de servidor o de SGBD, pero el diseño que hagas va a perdurar.

No creo que sea buena idea generar una BD por año y una tabla por máquina.
Yo generaría una tabla con la estructura completa y a partir de ahí utilizar índices y claves foráneas para acceder rápidamente a los datos que necesites. Si el volumen es demasiado grande puedes generar tablas de históricos con los datos más antiguos que ya no te interesen.