From: | "Marcelo Retamal" <mretamal(at)cmet(dot)net> |
---|---|
To: | "Lista Postgres" <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | [pgsql-es-ayuda] Problema con Entidad Relación |
Date: | 2006-08-28 20:50:11 |
Message-ID: | 001c01c6cae3$8e7224f0$da018282@mretamalxp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Me hubiese gustado representar el problema graficamente, pero estas serían las dos restricciones que nosotros manejabamos:
1.- Una relación no se puede relacionar con otra relación, lo que sería rvalor_paquete_stelevision relacionada con valor_paquete.
2.- En la tabla rvalor_paquete_stelevision existe un campo que tiene dos llaves foráneas (eso nos dejó plop).
Eso no más, atento a cualquier comentario.
----- Original Message -----
From: Carlos Alberto Márquez Rey
To: Marcelo Retamal
Sent: Monday, August 28, 2006 4:29 PM
Subject: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Problema con Entidad Relación
Que problema ven ustedes?
porque piensan que la idea de su compañero no esta ajustada a la Entidad/Relación, porque dicen que es descabellada?
No solo es que "aguante", eso seria si esta mal, pero es probable que la idea de su compañero sea buena y sea correcta, no lo digo con certeza porque no conozco el caso que desean modelar.
Marcelo Retamal <mretamal(at)cmet(dot)net> escribió:
Bueno... vale, de todas formas desvancamos la idea de mi compañero y le
dimos bastantes vueltas al asunto hasta que encontramos la solución ajustada
a la entidad/relación. En todo caso fue todo un día de discución y
entremedio risotadas. Como conclusión... de que agüanta, agüanta.
Nuevamente gracias.
----- Original Message -----
From: "Alvaro Herrera"
To: "Marcelo Retamal"
Cc: "Lista Postgres"
Sent: Sunday, August 27, 2006 3:59 PM
Subject: Re: [pgsql-es-ayuda] Problema con Entidad Relación
> Marcelo Retamal escribió:
>> Hola Lista, tengo un problema: aca en la of, tenemos una discución por
>> una diseño entidad relación, un compañero propuso un diseño medio
>> descabellado y para mal de nosotros lo llevó a la base postgres y lo
>> agüantó.
>
> Hola,
>
> Postgres aceptará cualquier diseño que sea sintácticamente válido. Si
> una persona es lo suficientemente idiota como para inventar un diseño
> que viola todas las normas establecidas de normalización, etc, o
> suficientemente brillante como para inventar una solucion novedosa a un
> problema dificil, y este esquema cumple con las restricciones
> sintacticas que Postgres impone, el esquema podrá ser creado, digamos
> "lo aguantará".
>
> Con respecto a este esquema en particular:
>
>> Etas son las tablas:
>> stelevision(
>> contrato,
>> servicio,
>> registro,
>> sucursal,
>> etc...,
>> llave primaria (contrato,servicio,registro,sucursal)
>> );
>>
>> valor_paquete [que es una relación](
>> sucursal [referencia de la tabla sucursal],
>> servicio [que es el mismo campo que está arriba y llave foranea de la
>> tabla servicio],
>> paquete [referencia de la tabla paquete],
>> etc...,
>> llave primaria (sucursal,servicio,paquete)
>> );
>>
>> rvalor_paquete_stelevision(
>> contrato,
>> servicio,
>> registro,
>> sucursal
>> paquete,
>> llave primaria (contrato,servicio,registro,sucursal,paquete)
>> );
>> constraint_1 (contrato,servicio,registro,sucursal) referenciado de
>> stelevision (contrato,servicio,registro,sucursal);
>> constraint_2(sucursal,servicio,paquete) referenciado de valor_paquete
>> (contrato,servicio,registro,sucursal,paquete);
>> Nota: el DELETE está en restrict y el Update está en cascade.
>>
>> En cuanto a diseño, hay un problema, pero el gestor lo agüantó, más
>> encima metió datos y no hay problema. Ahora la preguntá para los que
>> saben, ¿esa cosa está bien?
>
> Bien, yo no veo que haya ningun problema aca. El diseño incluso parece
> razonable. Pero en realidad no has publicado un esquema concreto, solo
> una descripcion ambigua. Si mostraras el esquema con lujo de detalles
> podriamos decirte mas certeramente si "esta bien" o "esta mal", o si "es
> una mala idea" o no lo es.
>
>> hasta ahora nosotros estabamos convencidos que no lo soportaba, más
>> una relación ser llave foranea de otra relación. A mi parecer el
>> problema está en la normalización y en enteder el problemas que es
>> bastante largo de explicar pero este diseño ¿qué problemas prodría
>> acarrear?.
>
> En principio yo no veo ninguno.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster
---------------------------(fin del mensaje)---------------------------
TIP 9: el optimizador ignorará el uso de recorridos de índice si los
tipos de datos de las columnas no coinciden
***********************************************************
Carlos Márquez
***********************************************************
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | fabian oswaldo vera jimenez | 2006-08-28 21:04:10 | necesito su ayuda!!!! |
Previous Message | jasi guerrero | 2006-08-28 20:09:32 | Re: equivalente del *= en postgres |