Relación imposible

[hach]

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

[[fjcg02]]

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

[roman]

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

[[Delphius]]

Y aqui llega el burro, que tira la patada

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,

[mamcx]

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.

[[coso]]

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.

pues si....

[tcp_ip_es]

Bueno bueno esto mas que un hilo parece un debate por partes...

Empezado por hach

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)

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

Empezado por fjcg02

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

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

Empezado por Roman

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.

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

Empezado por Delphius

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?

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 por supuesto que no es por ley, tu puedes hacer un contrato entre muuuuuchas partes, si fuera por ley ni pregunto al usuario

Empezado por mamcx

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.

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

Empezado por mamcx

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.

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