Re: Consulta teoria SQL (FK a dos tablas).

Si solo es por cuestiones de integridad podes implementar la FK con
triggers.
¿al fin y al cabo no son triggers las FK?

El día 11 de junio de 2008 14:04, Terry Yapt <yapt(at)technovell(dot)com> escribió:

> Raúl Andrés Duque Murillo escribió:
>
>>
>>
>> --------------------------------------------------
>> From: "Terry Yapt" <yapt(at)technovell(dot)com>
>> Sent: Wednesday, June 11, 2008 5:58 PM
>> To: <pgsql-es-ayuda(at)postgresql(dot)org>
>> Subject: [pgsql-es-ayuda] Consulta teoria SQL (FK a dos tablas).
>>
>> Hola a todos, a ver que opinais....
>>>
>>> Una cuestión básica, supongamos el siguiente esquema de tablas:
>>>
>>> http://www.technovell.com/mailinglist/supuestoIIX061101.jpg
>>>
>>> Donde un elemento de la tabla UNIDADES, puede ser un elemento UNICO (no
>>> estar incluido en ningún grupo) o bien estar incluido dentro de un grupo.
>>> La tabla entradas, es para las entradas de artículos. Puede entrar un
>>> artículo UNICO (Foreign Key a Unidades) o un artículo de Grupo (foreign Key
>>> de Grupos). Y he aquí el problema.
>>>
>>> Dicho esquema, está incompleto, pues la tabla entradas, tendría que tener
>>> una FK a la tabla UNIDADES _* Y *_ otra a la tabla GRUPOS. Pues de las
>>> dos tablas nos pueden venir entradas. Pero creo que esto no es posible, pues
>>> una de las dos FK (la que no se cumpliese) se quejaria en el momento de
>>> efectuar la carga de datos en la tabla ENTRADAS.
>>>
>>> Datos de ejemplo
>>> (Tabla Grupos):
>>> * _Tornillo*s*_
>>>
>>> (Tabla unidades):
>>> * Tornillo (pertenece a grupo _Tornillo*s*)._
>>> * Clavo
>>>
>>> (Tabla Entradas):
>>> * Tornillo, 01/01/2008, Entrada de UN Tornillo.
>>> * Clavo, 01/01/2008, Entrada de UN Clavo.
>>> * _Tornillo*s*, _01/01/2008, Entrada de UN grupo de Tornillos.
>>>
>>> Como se solucionaría, teoricamente, este problema ?????
>>>
>>>
>> Pues algo que se me ocurre (no se si aplica para la totalidad de tus
>> necesidades) es que tengas una UNICA tabla de "XUnidades" (fusionas Unidades
>> y Grupos) y en entradas tienes una FK a esta tabla "XUnidades".
>> Ahora para considerar la relación entre Tornillo y Tornillos, colocas una
>> relación circular para representar la relación "se compone de" o "es un
>> grupo de".
>>
>> Atentamente,
>>
>> RAUL DUQUE
>> Bogotá, Colombia
>>
>
> Hola Raul, efectivamente esa sería una forma, incluyendo su relación
> circular. El problema de las relaciones circulares es la obtención del arbol
> jerarquizado que, con Oracle, es una simple sentencia 'CONNECT BY PRIOR'.
>
> Pero START WITH ... CONNECT BY PRIOR, creo que no forma parte del estandar
> y, además, no está implementado en PostgreSQL, salvo en /contrib y, por
> principio, no deseo utilizar nada que no esté en el core....
>
> Si alguien tiene curiosidad de como funciona en Oracle:
>
> http://www.zonaoracle.com/manuales-tutoriales-oracle/consulta-jerarquica/index.asp
>
> El estandard, sin embargo, indica la utilización de: WITH recursive-sql
> .... (con muchos detractores, habituados a la sencillez del sistema en
> Oracle):
>
> http://www.sqlservercentral.com/articles/SQL+Server+2005+-+TSQL/recursivequeriesinsql1999andsqlserver2005/1846/
>
> Pero creo que tampoco está implementado en PostgreSQL, hasta la fecha,
> aunque parece que pronto... pronto...:
> http://archives.postgresql.org/pgsql-patches/2008-05/msg00362.php
>
> Bueno, lo tendré que pensar de otro modo...
>
> Gracias y un saludo..
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

--
Informático:
Persona falta de recursos que, partiendo de premisas falsas y de
especificaciones inconsistentes e incompletas, dirigido por incompetentes y
utilizando herramientas que no funcionan es capaz de iniciar un proyecto de
dudoso éxito realizando una obra de arte que ,por supuesto, es cara y no
tiene otro fin que dar prestigio a la empresa que ha contratado sus
servicios.
http://islamanzana.es/desarrollo-de-software/definicion-de-informatico