Estructura BD

[mjjj]

hola gente del foro.

Quiero plantearles una situación, y espero me puedan ayudar a decidir como desarrollar esto.

Necesito definir la estructura de BD para la siguiente situación.
Utilizo Delphi 2006 y Firebird 2.0.

Tengo que registrar 20 parametros distintos de tantos puntos como el usuario requiera. Le llamo punto al lugar en donde se estan adquiriendo los datos. De cada punto, en un instante obtengo 20 parametro distintos.

Mi idea es hacer un progrma que vaya consultando por todos los puntos instalados, e ir registrando estos parametros en una tabla, en donde registro la fecha, hora, dirección (punto) y los 20 parametros.

Ahora bien, se me ocurren varias formar de desarrollar esto, las expongo para que me sugieran cual utilizar y porque.

1. Una sola tabla en donde tengo los campos: fecha, direccion y los 20 parametros.

2. Una sola tabla en donde tengo los campos: fecha, direccion, parametro y valor. En donde tengo previamente definido que parametro representa a cual (por ejemplo con un entero del 1 al 20)

3.- Una tabla por cada punto con los campos: fecha y 20 parametros.

4.- Una tabla por cada punto con los campos: fecha, parametro y valor. En donde tengo previamente definido que parametro representa a cual (por ejemplo con un entero del 1 al 20)

Estas son las 4 opciones que se me ocurren,

preguntas:
cual escogerian ustedes?
Considerando que se estarán guardando registros cada 5 seg aproximadamente, cual opción hara mi BD mas eficiente, en cuanto a tamaño, velocidad de busqueda, registros, etc?
Alguna otra alternativa de estructura que se les ocurra?

Espero me pudan guiar para poder resolver esto de la mejor manera.

Saludos

[[duilioisola]]

Supongo que lo que te falta decir es qué es lo que vas a hacer con estos datos.

Si tienes que hacer cálculos con los 20 datos de un punto, te conviene tenerlos todo en el mismo registro.

Si tienes que sumarlos, sacar promedios, buscar mínimos y máximos, también creo que te conviene tenerlos todos en una misma tabla.

Si tienes que relacionar unos con otros, quizás te convenga tenerlos separados en diferentes tablas.

Espero que este comentario te sirva un poco...

[pnikkosis]

Coincido con lo de arriba, aunque me tiro mas por una tabla por cada punto.
Con una sola tabla que tenga como campos: fecha y hora (time stamp), punto, y despues los 20 parametros... se te va a complicar definir un primary key por ejemplo, o por lo menos no se me ocurre cual campo no tendrias duplicado. Con una tabla por cada punto despues es mas facil hacer selects, si queres ver la actividad de un punto especifico haces un select de su tabla correspondiente, y si queres ver la actividad de todos los puntos entre determinadas fecha y hora haces un select con un union; creo que tendrias que ver con que vas a trabajar, si tus consultas van a ser mas tirando a cada punto entonces hacelo por separado, porque vas a recorrer una tabla especifica. Pero bueno, si tenes que hacer operaciones matematicas siempre es mas facil cuando esta todo en la misma tabla.

[rgstuamigo]

Personalmente creo que no es hacerlo por hacerlo nomas,es decir se me ocurrio asi y asi lo hago;siempre hay que usar la teoria de Modelo_entidad-relación .Ya que esto me va permitir un buen orden,tablas integramente relacionadas,un buen diseño,facil matenimiento, y me va evitar problemas en el futuro..
Saludos...

[[Delphius]]

Empezado por rgstuamigo

Personalmente creo que no es hacerlo por hacerlo nomas,es decir se me ocurrio asi y asi lo hago;siempre hay usar la teoria de Modelo_entidad-relación .Ya que esto me va permitir un buen orden,tablas integramente relacionadas,un buen diseño,facil matenimiento, y me va evitar problemas en el futuro..
Saludos...

Pues, en realidad es un gran DEPENDE.
En ocasiones una normalización no es lo más aconsejable. Sobre todo en aplicaciones que recibirán datos casi en forma contínua y donde se requieren de cálculos y operaciones (sean estadísticas, probabilísticas, etc). Aquí se ha discutido del tema.

Existen la denormalización.

Saludos,

[rgstuamigo]

Empezado por Delphius

Pues, en realidad es un gran DEPENDE.
En ocasiones una normalización no es lo más aconsejable. Sobre todo en aplicaciones que recibirán datos casi en forma contínua y donde se requieren de cálculos y operaciones (sean estadísticas, probabilísticas, etc). Aquí se ha discutido del tema.

Existen la denormalización.

Saludos,

Pues aunque yo no hablé de Normalizacion especificamente,pues me temo que no se entedio mi comentario.
Lo que trate de sugerir(en mi humilde opinion) es que al momento de diseñar o crear una base de dato hay que tener en cuenta muchas aspectos, primero que nada debo utilizar algun patron de diseño que me brinde la oportunidad de estructurar bien mis tablas, de ahi que sugerí el modelo entidad-relacion muy bueno por cierto.
Ahora de que mis tablas las normalize pues creo que eso dependerá de quien las esté diseñando, talves el diseñador considere normalizar a una 1era. forma normal,o a una 2da Forma Normal , o 3era.FN, o 4ta.FN ,etc; eso ya depende de EL, pero si o si, mi sugerencia es que se utilize el Modelo Entidad relacion..
Saludos...