Re: UPdate en tabla con relacionamiento compartido

Carlos Alberto Márquez Rey escribió:
>
>
> */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)
>

Cierto, pero por cuestiones de ordenamiento de nodos dentro de un mismo
nivel podria darse el caso que fuera necesario cambiarlos.

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

Perfecto, el fk, como suponia, se encarga de realizar estos controles,
lo probaré.

El problema, tanto del triguer como de la fk, se presente ante un
restore de datos. Puede darse el caso de que el nodo 2 haga referencia a
un padre con id 5, en este caso el insert del restore fallará al
insertar el registro 2 puesto que el 5 todavia no existe.

Saludos,

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