Integridad referencial a través de triggers.

Hola, no se recomienda en lo absoluto hacerla por medio de triggers a menos
que se deba hacer entre bases de datos.


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


" José Luis" <JLB> escribió en el mensaje
news:
Mostrar la cita

Hola a todos,

estoy pasando una base de datos VFP a SQL Server 2005 a través de una
herramienta que proporciona VFP. He visto que la integridad referencial,
al igual que hace en la bd propietaria de VFP, la monta a través de
triggers. Mientras que si en SQL Server 2005 montas una integridad
referencial, creando un diagrama, no lo hace a través de triggers.

Mi pregunta si es recomendable tener la integridad referencial a través de
triggers o es preferible realizarla a través de la manera que lo realiza
el diagrama.

Muchas gracias por anticipado.

Un saludo,
José Luis.

José Luis,

Es preferible tener la integridad referencial de forma declarativa (usando
restricciones de clave foranea), pero hay veces que se debe recurrir al uso
de triggers. Un ejemplo es el que menciono Maxi. Otro ejemplo es cuando
queremos implementar las las operaciones de actualizacion y/o borrado en
cascada mediante codigo (en este caso mediante triggers). Si queremos
implementar esto ultimo, no podemos tener DRI puesto que SQL Server evalua
primero las DRI y en caso de estas fallar el trigger no es executado.

Ejemplo:

create table t1 (
c1 int not null identity(1, 1) primary key
)
go

create table t2 (
c1 int not null constraint fk_t2_t1_c1 foreign key references dbo.t1(c1)
)
go

create trigger tr_t1_del on dbo.t1
for delete
as
select 'Ni siquiera entra aqui porque la restriccion de clave foranea falla.'
delete t2
where exists(select * from deleted as d where d.c1 = t2.c1)
go

insert into t1 default values
insert into t1 default values
go

insert into t2 values(1)
insert into t2 values(2)
go

delete t1 where c1 = 2
go

select * from t1
select * from t2
go

alter table dbo.t2
drop constraint fk_t2_t1_c1
go

alter trigger tr_t1_del on dbo.t1
for delete
as
select 'Ahora si entra aqui porque ya no hay restriccion de clave foranea.'
delete t2
where exists(select * from deleted as d where d.c1 = t2.c1)
go

delete t1 where c1 = 2
go

select * from t1
select * from t2
go

drop table t2, t1
go


AMB


"José Luis" wrote:

Mostrar la cita

Hola a todos,

estoy pasando una base de datos VFP a SQL Server 2005 a través de una
herramienta que proporciona VFP. He visto que la integridad referencial, al
igual que hace en la bd propietaria de VFP, la monta a través de triggers.
Mientras que si en SQL Server 2005 montas una integridad referencial,
creando un diagrama, no lo hace a través de triggers.

Mi pregunta si es recomendable tener la integridad referencial a través de
triggers o es preferible realizarla a través de la manera que lo realiza el
diagrama.

Muchas gracias por anticipado.

Un saludo,
José Luis.

Hola Maxi y Alejandro,

muchas gracias por contestar mi mail. En principio no tengo pensado realizar
borrado en cascada por lo que esta parte no me afecta y enlace entre bases
de datos tampoco. Soy nuevo en el uso de SQL Server y viendo que los dos
motivos que me habéis dado no son mi caso, entiendo que me recomendáis
utilizar la integridad referencial de forma declarativa, me podrías
explicar, por favor, porque descartáis la forma mediante triggers en favor
de esta ?

Muchas gracias por vuestra ayuda.

Un saludo,
José Luis.
"Alejandro Mesa" escribió en el
mensaje news:
Mostrar la cita

José Luis,

Es preferible tener la integridad referencial de forma declarativa (usando
restricciones de clave foranea), pero hay veces que se debe recurrir al
uso
de triggers. Un ejemplo es el que menciono Maxi. Otro ejemplo es cuando
queremos implementar las las operaciones de actualizacion y/o borrado en
cascada mediante codigo (en este caso mediante triggers). Si queremos
implementar esto ultimo, no podemos tener DRI puesto que SQL Server evalua
primero las DRI y en caso de estas fallar el trigger no es executado.

Ejemplo:

create table t1 (
c1 int not null identity(1, 1) primary key
)
go

create table t2 (
c1 int not null constraint fk_t2_t1_c1 foreign key references dbo.t1(c1)
)
go

create trigger tr_t1_del on dbo.t1
for delete
as
select 'Ni siquiera entra aqui porque la restriccion de clave foranea
falla.'
delete t2
where exists(select * from deleted as d where d.c1 = t2.c1)
go

insert into t1 default values
insert into t1 default values
go

insert into t2 values(1)
insert into t2 values(2)
go

delete t1 where c1 = 2
go

select * from t1
select * from t2
go

alter table dbo.t2
drop constraint fk_t2_t1_c1
go

alter trigger tr_t1_del on dbo.t1
for delete
as
select 'Ahora si entra aqui porque ya no hay restriccion de clave
foranea.'
delete t2
where exists(select * from deleted as d where d.c1 = t2.c1)
go

delete t1 where c1 = 2
go

select * from t1
select * from t2
go

drop table t2, t1
go


AMB


"José Luis" wrote:

Mostrar la cita

Hola a todos,

estoy pasando una base de datos VFP a SQL Server 2005 a través de una
herramienta que proporciona VFP. He visto que la integridad referencial,
al
igual que hace en la bd propietaria de VFP, la monta a través de
triggers.
Mientras que si en SQL Server 2005 montas una integridad referencial,
creando un diagrama, no lo hace a través de triggers.

Mi pregunta si es recomendable tener la integridad referencial a través
de
triggers o es preferible realizarla a través de la manera que lo realiza
el
diagrama.

Muchas gracias por anticipado.

Un saludo,
José Luis.

On Mon, 10 Jul 2006 17:03:24 +0200, in microsoft.public.es.sqlserver
you wrote:

Mostrar la cita

muchas gracias por contestar mi mail. En principio no tengo pensado realizar
borrado en cascada por lo que esta parte no me afecta y enlace entre bases
de datos tampoco. Soy nuevo en el uso de SQL Server y viendo que los dos
motivos que me habéis dado no son mi caso, entiendo que me recomendáis
utilizar la integridad referencial de forma declarativa, me podrías
explicar, por favor, porque descartáis la forma mediante triggers en favor
de esta ?

Por principio siempre que se pueda se debe de optar por el código
declarativo.

El código declarativo es más productivo, más fácil de comprender y
modificar y menos propenso a errores.


Saludos

Hola Alfredo,

gracias por contestar a mi pregunta. No acabo de ver las ventajas que me
pueden aportar el uso de la DRI en lugar de triggers. He visto por varios
sitios que en efecto recomiendan DRI en lugar de triggers, pero no he
logrado averiguar el porque, es más lento, más seguro... es decir, teniendo
en cuenta que la herramienta de exportación de VFP me crea la base de datos
con la integridad referencial a través de triggers no he visto que ventajas
me puede traer el cambiar la integridad a través de triggers a DRI. Teniendo
en cuenta que no parto de 0 es tan significativa la diferencia entre la
manera de administrar una y otra como para que merezca la pena cambiarla?

Muchas gracias por anticipado y perdón por la insistencia, pero es que estoy
empezando a utilizar SQL Server y es un mundo bastante denso y me encuentro
algo perdido.

Un saludo,
José Luis.

"Alfredo Novoa" escribió en el mensaje
news:
Mostrar la cita

On Mon, 10 Jul 2006 17:03:24 +0200, in microsoft.public.es.sqlserver
you wrote:

Mostrar la cita

muchas gracias por contestar mi mail. En principio no tengo pensado
realizar
borrado en cascada por lo que esta parte no me afecta y enlace entre bases
de datos tampoco. Soy nuevo en el uso de SQL Server y viendo que los dos
motivos que me habéis dado no son mi caso, entiendo que me recomendáis
utilizar la integridad referencial de forma declarativa, me podrías
explicar, por favor, porque descartáis la forma mediante triggers en
favor
de esta ?

Por principio siempre que se pueda se debe de optar por el código
declarativo.

El código declarativo es más productivo, más fácil de comprender y
modificar y menos propenso a errores.


Saludos