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.

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

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

tabla contratos
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 :D

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.

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

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 :D

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

Pues yo aun sabiendo los detalles de la aplicación :D te hacen dudar ...muchas veces hay que ser vidente :D 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 :D. 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.

Me parece que las tablas como las planteas al comienzo estan correctas, eso te permite agregar mas partes e independizar tu codigo de la cantidad de partes que sean..
En cuanto al campo memo no me parece una buena solución ya que tendrás que ocuparte de mantenerlo actualizado, y tendrás datos redundantes. La idea de coso me parece buena: ver todas las partes en una columna (string separado por algun delimitador)
No es necesario que agregues un campo memo que luegos vas a tener que actualizar y mantener....
Simplemente puedes hacer un store procedure que te retorne todos los row de los contartos, y en una columna extra el string con las partes (y como dice coso, en otro string puedes retornar las id de las partes tambien con delimitadores, por si las necesitas)
Desde un store procedure es muy facil realizar esto.
Por cada contrato buscas todas sus partes y armas el string, y retornas los datos cada vez que cambia el contrato

El SP lo puedes utilizar tanto para llenar una grilla como para los listados

Saludos

Hola a todos,
y personalmente dejaría la estructura de las tablas normalizadas. Para visualizar las partes tal y como te indican un store procedure o un campo calculado en la tabla, de tipo string en el que concatenes los nombres de las empresas separados por un guión. Te valdrá para cuando haya uno o veinticinco, con sólo cambiar el ancho de la columna, que lo puede hacer hasta el tarado del usuario que pide esta memez ( si es capaz, claro ).

Saludos

Hombre, yo no creo que sea una memez, ni mucho menos que el usuario sea un tarado. Uno no sabe cuáles son sus necesidades ni porqué desea ver la información de tal o cual manera. Así como no es deseable que un cliente nos diga cómo programar, tampoco es deseable decirle a él como debe hacer las cosas.

Yo le he propuesto a Tony lo del demo simplemente porque a veces el usuario puede no haber contemplado cierta posibilidad, pero eso no lo convierte en estúpido.

En cuanto a la concatenación, yo la haría mostrando cada empresa en una línea porque si las ponemos en una sóla, además de que visualmente puede no ser agradable o claro, puede generar una columna demasiado ancha.

// Saludos

Y aqui llega el burro, que tira la patada:D

No es porque esté en contra de una u otra postura. Se han propuesto muchas alternativas, cada una tiene sus ventajas y desventajas.
Nomás me paso por aquí para preguntar algo ¿Que tan alta es posibilidad de que exista un cambio en alguna ley/norma/artículo/etc y afecte el modo en que se compone un contrato?

Si el cliente te asegura, de que no hay más de 4 partes es por algo. Lo que se debería averiguar y analizar porque son 4 y no 50 (por decir un número exagerado). Muy posiblemente se deba a una imposición legal. Por tanto la pregunta que debería hacerse a estas alturas ¿Exista una altísima posibilidad de que haya modificaciones en la ley civil que regula el sistema contractual?

La idea del desarrollo de la demo es muy buena, sobre todo cuando los requisitos no son muy claros.

¿A que viene el rollo que estoy soltando?
A que a lo mejor por normalizar, y por prepararse a un cambio (que ni siquiera se sabe que pueda ocurrir, y que es posible que nunca ocurra) se "complica" el diseño de la base de datos.
Tal vez tener una tabla desnormalizada no es mucho problema.

Mejor analizar si es posible y viable la idea del cambio antes de estar gastando esfuerzo inútil en prepararse a algo que tal vez nunca ocurra.

¿Se entiende a lo que voy?

Además, en el caso de que en un futuro se exija tener más partes, tu tendrías el tiempo de preparar tener diseñado ya una nueva versión del sistema. Lo cual te permitiría hacer mejores negocios con el cliente.

Nomás digo, no es que se me deba hacer caso. Es mi humilde punto de vista.

Saludos,

Claro.

Yo trabaje (mi primer empleo!) en una firma de abogados y es cierto que es todo un lio manejar esos documentos. Y me parece muy raro el requerimiento. Sera que una BD es la mejor opcion? Esto es un problema de datos no estructurados.... en fin.

Una opcion mas y que tambien uso es la de los dataset en memoria. La idea es armar la estructura del clientdataset tal como se quiere ver y "por dentro" hacer los enlaces. La ventaja es que existe la flexibilidad de hacer cambios luego y se da una vision al usuario tal como quiere.

Tambien es valido y quizas mejor desempeño hacer una vista que usando triggers se hacen las actualizaciones. O con grid poderosos como los de DevExpress.

Lo que me da cosa con todo esto es que no me "entra" la idea de cojer un documento que a la final es como una carta, partirlo y luego ensamblarlo... no se, me parece poco natural.

Quizas seria bueno que exploraras bien el asunto en lapiz y papel. Tambien, leer un poco como se tratan datos no estructurados y como se usan tags para relacionarlos con la bd.

pues si....

:D Bueno bueno esto mas que un hilo parece un debate ;) por partes...

Gracias Hach, buena idea va en la línea de lo que quiero montar y asi me ahorro un campo aunque me tendréis que ayudar con el store procedure ;)


:D je je cuando le enseñe la demo lo verá de otra manera a veces hay que ser buen comercial para acabar trabajando como tu quieres....

esta bien la idea pero como el dbgrid que utilizo (estandar) solo muestra una fila(no puedo ampliar el alto de la misma) al final por cada contrato solo se verá la primera empresa, ahí tengo que ver como lo hago.....

Te digo como llego a la conclusión el usuario de que quería cuatro campos:
"Actualmente tenemos unos 200 contratos y en ninguno he superado las tres partes asi que ponme 4 campos que seguro que no llegamos a más"; ante eso uhmmm opté por hacer variable ese campo :D por supuesto que no es por ley, tu puedes hacer un contrato entre muuuuuchas partes, si fuera por ley ni pregunto al usuario :p

La necesidad que le surge al usuario es digitalizar los contratos y tenerlos accesibles via pc, actualmente cada vez que quieren ver algo de un contrato o escritura tienen que ir a la caja fuerte, abrirla y ver los datos que necesitan, con la aplicación lo verían ipsofacto

uhmmm estudiaré tus opciones... en cuanto a DevExpress intento no instalarme nuevos componentes para desarrollar y eso que tengo D5 :D