Relación imposible

[tcp_ip_es]

Muchas gracias Nelet, es buena idea pero compleja para implementar, veo más conveniente crear un memo con las partes implicadas en el contrato como dijo coso, es más práctivo a la hora de mostrar un dbgrid o exportarlo a un excel... pero repito muchas gracias por la solución....

[Nelet]

Empezado por tcp_ip_es

Muchas gracias Nelet, es buena idea pero compleja para implementar, veo más conveniente crear un memo con las partes implicadas en el contrato como dijo coso, es más práctivo a la hora de mostrar un dbgrid o exportarlo a un excel... pero repito muchas gracias por la solución....

De nada, que pa eso estamos...

Y además, no había caído en que coso ya te sugirió esa opción. Xe, me hago mayor y no leo todo.

[mamcx]

Eso es muy simple.

Hace unos años (en 1999!!) me toco hacer el rediseño de la entrada de notas u hoja de calificaciones.

Si miran un reporte de esos, veran que es una columna con nombres y una columna por cada periodo de notas (que pueden ser hasta 12....)

Y si, la idea original era un miercolero de selects y funciones en fox. Luego se me ocurrio que cual era el lio de simplemente clavar las columnas directamente en la estructura? Asi que queda masomenos:

idAlumno, idMateria, obs1...obs2, otros campos

Y !zaz! se simplifico el codigo que da miedo, y los reportes salieron mas facilitos!

A veces, hay que perderle el miedo a desnormalizar. Desde entonces aprendi que la funcion de una estructura de BD no es la normalizacion, sino la adaptacion mas natural para la aplicacion (y generalmente es la forma de entrada de datos mas comun).

[tcp_ip_es]

¿Es decir que tu solución al problema sería la siguiente?:

tabla contratos

Idcontrato
Parte1
Parte2
Parte3
Parte4
Fechaentradavigor
FechaFirma
TipoContrato
etc

y entonces, cuando me dijesen que existe una nueva parte, tu lo que harías es crear un campo nuevo no???

Realmente desnormalizas, pero no te digo yo que me dan ganas de hacerlo porque te ahorras dolores de cabeza

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

Empezado por tcp_ip_es

...pero no te digo yo que me dan ganas de hacerlo porque te ahorras dolores de cabeza

Piensa a la larga, no sea que los dolores de cabeza que te ahorres ahora, se conviertan en errores más grandes dentro de un tiempo...

[tcp_ip_es]

ja ja ja no si por eso lo digo Neftali, ya hace varios post he decidido implementar la idea de coso (maestro->detalle + campo memo informativo en maestro con los datos del detalle para consultas) , pero en un principio me pense plantar los 4 campos de partes y a tomar vientos

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

Empezado por mamcx

Desde entonces aprendi que la funcion de una estructura de BD no es la normalizacion, sino la adaptacion mas natural para la aplicacion (y generalmente es la forma de entrada de datos mas comun).

El problema es que muchas veces la aplicación está mal diseñada, por lo tanto la adaptación más natural para la aplicación es errónea.

Sigo pensando que esa estructura no es correcta. No es buena para almacenar información (puesto que no es fija -numero fijo de campos-), no es buena para mostrar información (por lo que ya se ha comentado antes) y no es buena para recuperar información (puesto que no está normalizada); Esto último implica que lo que apriori parace más sencillo luego se vuelva más complicado y lento.

Por ejemplo, buscar o agrupar los contratos que tienen partes con una empresa; Calcular el importe facturado a una empresa (a partir de los partes a esa empresa) o los contratos que tienen algun parte de una determinada Clase.
1º) para esto vas a tener que empezar a hacer:
... OR PARTE1 ... OR PARTE2 ...OR PARTE3...
2º) Si mañana se necesitan 5 partes, en lugar de 4, además de cambiar las inteficies, vas a tener que cambiar las consultas.

No digo con esto que la normalización se tenga que llevar a "raja-tabla", yo mismo en casos muy puntuales he "desnormalizado", pero creo que este caso no lo justifica; Es mi opinión, pero creo que esa solución es una pésima opción.

[roman]

Yo estoy de acuerdo con Neftalí. Sin saber más detalles acerca del sistema en particular, no es posible determinar si una denormalización es conveniente o no. De que lo hacemos lo hacemos. Yo tengo una tabla de personas con dos campos para teléfonos. Estrictamente hablando tendría que que separarlos en una tabla aparte pero no hay ningún viso de que en algún futuro sea necesario, así que, no hay necesidad.

Pero si existe esa posibilidad -y hablando de empresas que forman parte de un contrato, da la impresión de que así será- no puede evitarse la mormalización.

Y, como menciona el mismo Neftalí, muchos reportes se complicarán terriblemente por no haber normalizado.

Vamos, que la normalización no es un concepto que alguien se fumó por ahí.

// Saludos

[tcp_ip_es]

Pues yo aun sabiendo los detalles de la aplicación te hacen dudar ...muchas veces hay que ser vidente El usuario me jura y perjura que en un contrato solo abrá 3 partes a lo sumo 4. Pero claro yo no me fio y por eso normalizo y saco la tabla partes fuera de la tabla contratos.

Luego tengo la tabla Escrituras de Poder* y me pasa lo mismo, el usuario me dice que como máximo en una escritura puede haber 8 apoderados, pero como antes yo no me fio y normalizo sacando la tabla apoderados fuera de la tabla escrituras.

Es dificil ser vidente y por eso me cubro en salud normalizando, lo único que a priori y para informes quizás es más facil desnormalizar, porque imaginate que tu normalizas tu tabla de personas y sacas la tabla teléfonos, y ahora te piden el informe -> Persona Telefono1 telefono2 telefonoX.... MasDatos ....

Yo de momento voy a normalizar e incluire un campo en el maestro con todos sus detalles . Haré una demo, como bien me dijistes y trataré de convencerles



(*) Papeles que otorgan poder a cierta persona/s , por ejemplo un empresario otorga el poder de firmar facturas a su empleado pepito y juanito.