Re: UPdate en tabla con relacionamiento compartido

Oswaldo Hernández <listas(at)soft-com(dot)es> escribió: Jean Marcel Droguett A. escribió:
> Mario Gonzalez wrote:
>
>> Creo que lo malo de hacer eso es que no se podria garantizar una
>> integridad relacional, me tratare de explicar.....
>>
>> Si tienes esto en tu DB
>>
>> id Nombre idSuperior
>> 1 Jefe 1
>> 3 Nombre 1 1
>>
>> como podrias impedir una insercion como esta (suponiendo que la
>> tabla se llama users)
>>
>> INSERT INTO users(nombre, idSuperior) VALUES ('Nombre3', 3)
>>
>> y el resultado seria que el jefe de 'Nombre3' es un empleado
>> ('Nombre1')!!
>>
>> id Nombre idSuperior
>> 1 Jefe 1
>> 3 Nombre 1 1
>> 5 Nombre 3 3
>>
>> podrias hacer un parche con triggers o programando una funcion que
>> te cubra eso pero quizas teniendo otro tipo de modelo pudiera
>> solucionarse.
>>
>>
>
> Yo creo que es exacmente eso lo que se quiere con esta tabla relacionada
> así mismo, se quiere crear una jerarquía de empleados donde hay jefes en
> los distintos niveles del árbol
>
>

Yo lo estoy haciendo mediante un trigger que realiza basicamente los
siguientes controles:

Delete:
- si el nodo tiene hijos -> error

Update:
-si se ha cambiado la referencia al padre:
comprueba que existe
comprueba que no se referencia a si mismo
si el padre es null, comprueba que no existe ya un nodo raiz
- si se ha modificado el id de nodo -> error
(en este caso habria que modificar la referencia de sus hijos o hacer
que el campo idpadre una fk a idnodo con update cascade, si postgres lo
permite - por ver -)

Insert:
- comprobacion de validez del padre (igual que en update)

Para el soporte a este modelo he diseñado una serie de funciones que
delvuelven las rutas completas de un nodo, lista de un nodo con todos
sus hijos, nº de hijos que contiene, etc.

El esquema es perfectamente válido y proporciona mucha flexibilidad para
realizar organizaciones en arbol.

Saludos,
--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

---------------------------(fin del mensaje)---------------------------
TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

El id no deberia cambiar (ningun id debe cambiar)

y para realizar lo que hace el trigger que comentas bastaria con poner una FK entre el id y el id_padre

Ejemplo:

id dato id_padre
1 padre1
2 padre2
3 dato1 1
4 dato2 1
5 dato3 2

Delete si quiero borrar el registro 1 no puedo porque esta relacionado mediante FK a los registros 3 y 4

Update en el registro 5 puedo updatear el campo id padre por cualquiera de los otros id
menos del mismo (esto ultimo si debiera controlarse por trigger) el FK controla que exista un id para poder ponerlo en id_padre

Insert

el FK controla que exista un id para poder ponerlo en id_padre


la sentencia para esta FK seria:

ALTER TABLE tabla ADD FOREIGN KEY (id_padre) REFERENCES tabla ON DELETE RESTRICT;

***********************************************************
Carlos Márquez
***********************************************************
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/