FTP | CCD | Buscar | Trucos | Trabajo | Foros |
#1
|
|||
|
|||
Estructura BD
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 |
#2
|
||||
|
||||
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... |
#3
|
||||
|
||||
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. |
#4
|
||||
|
||||
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...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
Última edición por rgstuamigo fecha: 07-12-2009 a las 14:04:20. |
#5
|
||||
|
||||
Cita:
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, |
#6
|
||||
|
||||
Cita:
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...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
|
#7
|
||||
|
||||
Cita:
Yo lo entendí a que siguiera la normalización. La cosa es que de una u otra forma, tal vez indirecta o implícitamente, el llevar un correcto DER nos impulsa a seguir la normalización y sus reglas normales. Dije correcto, porque la primera impresión que nos llevamos cuando abordamos el diseño del DER es seguir un diseño basado en las relaciones conceptuales entre las entidades. Y por lo general, esto termina en una estructuración de dichas entidades y relaciones. Luego uno normaliza respetando esa conceptualización (se pueden esperar algunos cambios y excepciones, pero en lo general busca respetarla). El asunto es que en ocasiones, ese pensamiento no es el más adecuado, y por tanto debe analizarse desde otro punto de vista (otro nivel de abstracción), no tan conceptual y basado en las entidades sino más bien desde la funcionalidad/facilidad de las operaciones esperadas. Es decir, lo inverso: hacer que el diseño (y por tanto sus tablas y relaciones) se ajusten al conjunto de datos esperados para facilitar las operaciones. Saludos, |
#8
|
||||
|
||||
Cita:
¿Que siga su instinto y lo diseñe conforme a su propia forma de trabajo sin seguir ningun patron de diseño?... total que funcione y listo... Disculpa no acabo de entenderte. Ten encuenta que el amigo mjjj es quien realmente va definir su forma de trabajo,solo estaba pidiendo opiniones y/o sugerencias, en mi caso solo le estaba haciendo saber que existen mecanismos(Patrones)que se pueden seguir para un buen diseño. Saludos...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
Última edición por rgstuamigo fecha: 05-12-2009 a las 18:02:43. |
#9
|
||||
|
||||
Esto parece un teléfono descompuesto.. ninguno de los dos nos entendemos
A ver si me explico: Cuando uno empieza con el análisis del DER siguiendo el Modelo Entidad Relación que comentas, sigue un proceso que se basa, por lo general y mayormente, en identificar las entidades, sus relaciones y de allí en más continuar con una normalización. Es más, implícitamente el proceso busca la normalización. En este proceso en ocasiones no se contempla, o mejor dicho: no es fácil distinguir y apreciar, posibles entidades abstractas no contempladas en el contexto puesto que el diseño busca respetar las reglas normales. Y muchas veces, este diseño en búsqueda de optimizar los datos no logra ofrecer una estructura más adecuada a los verdaderos y prioritarios intereses, funcionalidades y requisitos. Si se optara por la vía inversa y se analizara los conjuntos de datos esperados para las operaciones y funcionalidades, es posible apreciar aquellas entidades abstractas y de interés. Luego, se diseñan las tablas siguiendo este enfoque. Es mucho más complicado de hacerlo, y en ocasiones complica el diseño lógico de la base de datos, pero estas inconsistencias lógicas permiten acelerar y facilitar las operaciones que de otro modo sería mucho más rebuscado si se optara por una correcta normalización. Se trata de un grado diferente de abstracción, y quizá no necesariamente diferente... sino más bien complementario. Algo similar sucede con los patrones OO: mucho es complicado, poco nos da un diseño débil... ¿el adecuado?... quien sabe. Como todo héroe tiene su archi enemigo: anti-patrones. Si quieres lo resumo en lo siguiente: ¿Lógicamente correcto, o funcional y operativamente correcto? No digo que lo deje solamente a su instinto (que dicho sea de paso es un condimento que hay que seguirlo puesto que nos lleva a adquirir experiencia), tampoco hay que dejarnos llevar en exclusiva por los "patrones" que dices. La cuestión es que no existe un proceso debidamente formal, en como debe encararse una denormalización (al menos, yo lo desconozco). Y eso se debe a que se trata de algo fuera de la norma, de lo esperado. Es cierto que quien debe tomar la decisión es mjjj. Lo que yo quería demostrar es que se tome con pinzas el proceso de Modelo que tu dices. Recuerda que todo modelo no es infalible, que puede fallar. Funcionará bien siempre y cuando se respete y se sigan sus sus axiomas, teoremas, lemas, etc. En el momento en que se intenta amoldar algo no contemplado las cosas no funcionan como esperaríamos. Y se necesita readaptarlo, o asumir cierto grado de rigor. Saludos, |
#10
|
||||
|
||||
Bueno...para que seguir dando vueltas en el mismo asunto, si tanto tú como yo tenemos diferencias en como encarar esta situacion.
En mi caso siempre trato de poner en accion la teoría,aunque que a veces no este de acuerdo, pero me ha dado muy buenos resultados. Confieso que muchas veces al querer implementar un nuevo sistema me han surgido miles de cuestiones(tal como el amigo mjjj ),pero gracias a DIOS he recordado que en algun momento en mi Universidad, en alguna Materia, ya habia aprendido o se había hablado del tema y de ahí, muchas veces e ido profundizando hasta poder tener o sacar una buena solucion alos problemas que se me pueda presentar,desde luego tambien aqui en el Club he recibido la ayuda de muchos. Y esto es obvio, por que sino aplico lo que he aprendido,pues entonces para que ir ala Universidad?. De todas formas creo que el amigo mjjj, ya puede sacar sus conclusiones y ojalá pueda implemetar su Aplicacion de la mejor manera posible. Lo que menos se quiere, es confundirlo más, con tantas opiniones. Saludos DELPHINEROS...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
|
#11
|
||||
|
||||
Cita:
Yo también soy de la idea de que debe seguirse en lo posible el Modelo Entidad Relación y poner en práctica lo que me haya ofrecido la teoría y el abanico de conocimientos dados en la universidad. Lo que yo digo es que no debe tenerse una visión cerrada y confiar en que SIEMPRE la teoría funcionará en la práctica. Cito un mensaje tuyo: Cita:
Lo vez demasiado teórico, en mi humilde opinión. Y lo digo porque esto me trae el recuerdo de aquella discusión sobre UML. Hay que contar además el factor humano, que después de todo los modelos que proponemos llevan impreso el mismo defecto que nosotros: ¡somos humanos y podemos equivocarnos! Y si nosotros nos equivocamos, nuestros modelos también. ¿Seguirías aplicando el modelo si se comprobara que tiene fallas? ¿Hasta donde asumes que el modelo es viable? ¿Cuántas fallas aceptarías? En el diseño de una base de datos se debe sumar la experiencia, y otra serie de factores. Yo a como lo veo, en mi humilde opinión, el modelo no deja de ser más que un modelo: una guía práctica, más no un libro exacto. No se... quizá sea que yo por naturaleza soy un tanto desconfiando. Si hay algo que aprendí es a no quedarme únicamente con lo dicho en la universidad, que naturalmente tienden a ser teóricas (Y te lo dice alguien que es naturalmente teórico). Por mi cuenta busco aprender, investigar, razonar y cuestionar y debatir sanamente los porqués de esto y aquello. Tampoco es para llegar al absurdo y extremo como dudar de si 2+2=4. Pero a lo que voy es que la teoría bonita es, pero en la práctica no siempre resulta ser lo que es. Tu dices que acudes a otras fuentes, que consultas, y aprendes. Haces bien... pero no es por ser malo... entonces contradices lo que haz dicho anteriormente, que siempre hay que seguir el modelo. Cita:
... Entonces ¿aplicas el modelo o lo haces así por hacer o le imprimes lo nuevo que aprendes? rgstuamigo, no se como será la formación universitaria que recibes. No estoy en poder de criticar, sólo quiero hacerte notar que es bueno dudar y cuestionarse las teorías y como aplicarlas. No aplicar por aplicar sólo porque la universidad lo dice. Muchas cosas que se dicen en la universidad lo aplicas, otras las aplica de otra forma... ¿Eso es malo? ¿El poner en práctica, algo como no te lo han enseñado, está mal? No es por llevarte la contraria. Es para proporcionar una visión complementaria. Me dejas la impresión de que te cuesta aceptar que el gris puede existir. Ya dirá mjjj que es lo que conviene. Y Tienes razón, no deberíamos ensuciar, otra vez, el hilo. Saludos, |
#12
|
||||
|
||||
Cita:
Creo que nos estamos yendo por la tangente... y olvidando la secante... Si tú le has encontrado fallas al Modelo Entidad Relacion, pues creo que deberias decirnos que Problemas tiene? o en todo caso podrias escribir o hacérselo saber al Dr.Peter Chan, desde luego no quiere decir que es lo maximo,pero si no estas de acuerdo en su uso ,simplememte puedes recomendar no usarlo y listo, y creo que todos respetaremos tu opinion aunque no la compartamos; en mi caso, siempre la uso aunque no en toda en su magnitud, por que la teoriá en extensa. Cita:
Cita:
La universidad te enseña, mas eres tú quien decide si aplicas o no lo aprendido. Ademas el Modelo entidad relacion no solo se aplica en las universidades,Cualquier persona de cualquier status social,religion,profesion,etc. puede aprenderlo,aun sin ir a una universidad. Y el hecho de aplicarlo o no aplicarlo pues dependerá de él. Pero la teoría esta Alli. Saludos...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
|
#13
|
|||
|
|||
Amigos, despues de tantas respuesta y opiniones les comento le que he realizado.
En primer lugar todas las operaciones que requiero hacer siempre se realizan sobre un solo punto, lo que me lleva a decidir tener una tabla por cada punto. Según, me percaté que al tener una tabla con 20 campos para als distintas variables, el tamañp de la BD crece, considerablemente mas rapido que si tuviese solo 2 campos valor y parametro... por el contrario, la cantidad de registros será mayor, y las busqueda serán las lentas. Creo que finalmente lo quemas me conviene es tener una talba por cada punto, con los 20 parametros. Espero tengan sugerencias de lo comentado. Saludos |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Estructura de FireBird !? | pmtzg | Conexión con bases de datos | 2 | 19-12-2007 22:13:12 |
Errores de estructura...?? | andresenlared | Firebird e Interbase | 2 | 29-06-2006 21:06:59 |
Liberar estructura | Coco_jac | Varios | 5 | 12-12-2005 21:42:11 |
Estructura de un CD | david duarte | Varios | 4 | 27-10-2005 17:48:50 |
estructura de una tabla | Salomon | Firebird e Interbase | 3 | 14-05-2004 15:26:46 |
|