Relación imposible

[roman]

¡Ah vaya! Ni siquiera me había fijado en la pregunta exacta de Tony . Gracias por la aclaración Eliseo, quien quita y se acostumbran a nuestras expresiones .

// Saludos

[[egostar]]

Empezado por roman

¡Ah vaya! Ni siquiera me había fijado en la pregunta exacta de Tony . Gracias por la aclaración Eliseo, quien quita y se acostumbran a nuestras expresiones .

// Saludos

Chance y si

Salud OS

[tcp_ip_es]

Edite la url del link, espero que ahora se vea correctamente.

Efectivamente quien quita que no entendiese la frase hecha "quien quita" . Aqui vamos entendiendo ya toda vuestra jerga, somos minoría

Lo que dices sobre el maestro detalle con los dos dbgrid ya estaba en mi cabeza, si lo que pasa es a la hora de los informes, pero bueno como bien dices...

Empezado por Roman

Yo comenzaría preguntándole al cliente qué espera ver en todos los recuadros en blanco que quedarán. Porque donde un contrato esté asociado a diez empresas y los restantes sólo a dos o tres, va a haber muchos huecos sin sentido.

[Nelet]

Ahí va una idea:

Antes de presentar el dbgrid o el informe podrias calcular el máximo número de partes que vas a obtener.

Una vez obtenido el número de columnas que vas a necesitar solo tendrías que montar una query añadiendo las columnas necesarias.

Por ejemplo, esto funcionaria en sqlserver. En mysql creo que es parecido,

Código SQL [-]
SELECT COUNT(ID_PARTES) FROM PARTES_CONTRATO WHERE ID_CONTRATO IN("LISTA DE CONTRATOS")

Código SQL [-]
select id_contrato, 
case when id_parte=1 then ID_EMPRESA else "" end,
case when id_parte=2 then ID_EMPRESA else "" end,
.....
case when id_parte=numeropartes then ID_EMPRESA else "" end,
FechaFirma, FechaEntradaVigor, Objeto, IdTipoContrato
from contratos a 
inner join PartesContrato b on
a.id_contrato=b.id_contrato
where a.id_contrato in(..lista de contratos..)

Esto lo puedes ir formando en un query y así obtener de forma dinamica las columnas que necesites. De esta forma el contrato con el máximo numero de partes tendría todas las columnas rellenas y los restantes columnas en blanco donde no existiese el id_parte.

Todo esto se puede hacer siempre y cuando el ID_PARTE sea secuencial.

Espero haberte ayudado en algo.

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

[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