Cuando se recomiendan los triggers ?

en los años que me dedico a esto de la informatica me di cuenta que las
cosas genericas que dicen funcionar en todos lados, a la larga son un
problema.. pero bue es tema para discutir en otro momento ;-)

Igual pasa con tomar los libros al pie de la letra. A veces la experiencia
práctica nos da en la cara.:)

En cuanto al ejemplo: Si tienes un procedimiento que hace inserta un
cheque, para que quieres un trigger? No seria mas facil tener todo el

codigo

junto (funcionalmente agrupado) y de mas facil mantenimiento. Si decides

no

tener un Procedimiento de Cheques, tiene mucho sentido hacer un Trigger.

Oye Javier,

1) se podria configurar un SP unico que sea tanto para insertar como para
borrar o para actualizar una tabla ?

2) Cuando hablas de un procedimiento de Cheques para este ejemplo, quieres
decir que en vez de mandar un insert desde la aplicacion, lo que se haga sea
mandar llamar el procedimiento almacenado con los datos de las columnas como
parametros ?

3) Si uno decide usar sp para actualizaciones, implicaria entonces tener un
SP para cada tabla actualizable del sistema ?

Finalmente) Podrias poner aqui (tu u otra persona del foro) algun ejemplo
de un SP que se utilice para insertar un registro y hacer algunas otras
cosas posteriores (como se hace en un trigger) ?


Gracias
Andres Ledesma

Hola:
1) Si se se puede (como la Seleccion de Football de Costa Rica :D)
CREATE PROCEDURE MantenimientoAutores(
@Accion as varchar(3)
, @au_id id
, @au_lname varchar(40)
, @au_fname varchar(20)
, @phone char(12)
, @address varchar(40)
, @city varchar(20)
, @state char(2)
, @zip char(5)
, @contract bit
)
AS
SET NOCOUNT OFF;
BEGIN TRAN
IF @Accion='DEL'
BEGIN
DELETE FROM authors
WHERE (au_id = @au_id)
END
IF @Accion='INS'
BEGIN
INSERT INTO authors(au_id, au_lname, au_fname, phone, address, city,
state, zip, contract)
VALUES (@au_id, @au_lname, @au_fname, @phone, @address, @city, @state,
@zip, @contract)
END
IF @Accion='UPD'
BEGIN
UPDATE authors
SET au_lname = @au_lname, au_fname = @au_fname
, phone = @phone, address = @address, city = @city, state = @state
, zip = @zip, contract = @contract
WHERE (au_id = @au_id)
END
COMMIT

No lo recomendaria, pero poder se puede. La principal razon por la que
no me gusta, es que no puedo otorgar permisos espeficicos para
Insertar/Borrar/Actualizar de forma separada quitando un elemento importante
de los Procedimientos que es seguridad.
2) Exactamente. Este fue durante mucho tiempo la "recomendacion general"
en el sentido que permitia gran flexibilidad, seguridad y desempeno. Pero
con el tiempo y el desarrollo de n-capas ya no es "tan importante" la
seguridad en la base de datos sino que es una funcion de los componentes de
capa media que brindan en estos servicios. En mi caso, me mantengo usando
procedimientos almacenado sobre todo por la independencia de las tabla, pero
entiendo la posicion alterna.
3) Exactamente. Ese es para mi uno de los imporantes limitaciones de
este esquema, la generacion del codigo inicial. Debido a que Visual
Studio.NET hace facilisimo la generacion de codigo ya no es tan importante
la objeccion, es casi como que Visual Studio "sugiriera" usar este esquema.
Sobre el SP, tal vez un procedimiento de Borrado (1/2 suicida) te sirva
de ejemplo:
CREATE PROCEDURE BorraAutoresConLibros(
@Accion as varchar(3)
, @au_id id
)
AS
BEGIN TRAN
DELETE sales
FROM Sales
JOIN titleauthor
ON Sales.Title_ID=TitleAuthor.Title_ID
WHERE TitleAuthor.Au_ID=@Au_Id

DELETE titleauthor
WHERE (au_id = @au_id)

DELETE authors
WHERE (au_id = @au_id)
COMMIT
Espero te sirva,



Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"El principiante" wrote in message
news:

> En cuanto al ejemplo: Si tienes un procedimiento que hace inserta un
> cheque, para que quieres un trigger? No seria mas facil tener todo el
codigo
> junto (funcionalmente agrupado) y de mas facil mantenimiento. Si decides
no
> tener un Procedimiento de Cheques, tiene mucho sentido hacer un Trigger.

Oye Javier,

1) se podria configurar un SP unico que sea tanto para insertar como para
borrar o para actualizar una tabla ?

2) Cuando hablas de un procedimiento de Cheques para este ejemplo, quieres
decir que en vez de mandar un insert desde la aplicacion, lo que se haga

sea

mandar llamar el procedimiento almacenado con los datos de las columnas

como

parametros ?

3) Si uno decide usar sp para actualizaciones, implicaria entonces tener

un

SP para cada tabla actualizable del sistema ?

Finalmente) Podrias poner aqui (tu u otra persona del foro) algun ejemplo
de un SP que se utilice para insertar un registro y hacer algunas otras
cosas posteriores (como se hace en un trigger) ?


Gracias
Andres Ledesma

Tal cual!! yo tenia un amigo que desde muy chico me decia: Mira, los libros
son hermosos para ponerte en tema, pero luego en la cancha se ven los
pingos!! y la verdad que hay muchas cosas que uno con la experiencia se da
cuenta que no son tan asi como se expresan en los libros!! por suerte
estamos en un rubro donde vale mucho todo esto :-D




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messager:

"Ricardo Passians" escribió en el mensaje
news:%

en los años que me dedico a esto de la informatica me di cuenta que las
cosas genericas que dicen funcionar en todos lados, a la larga son un
problema.. pero bue es tema para discutir en otro momento ;-)

Igual pasa con tomar los libros al pie de la letra. A veces la
experiencia
práctica nos da en la cara.:)

Muchisimas gracias, amigo.



"Javier Loria" wrote in message
news:%

Hola:
1) Si se se puede (como la Seleccion de Football de Costa Rica :D)
> CREATE PROCEDURE MantenimientoAutores(
@Accion as varchar(3)
, @au_id id
, @au_lname varchar(40)
, @au_fname varchar(20)
, @phone char(12)
, @address varchar(40)
, @city varchar(20)
, @state char(2)
, @zip char(5)
, @contract bit
)
AS
SET NOCOUNT OFF;
BEGIN TRAN
IF @Accion='DEL'
BEGIN
DELETE FROM authors
WHERE (au_id = @au_id)
END
IF @Accion='INS'
BEGIN
INSERT INTO authors(au_id, au_lname, au_fname, phone, address, city,
state, zip, contract)
VALUES (@au_id, @au_lname, @au_fname, @phone, @address, @city, @state,
@zip, @contract)
END
IF @Accion='UPD'
BEGIN
UPDATE authors
SET au_lname = @au_lname, au_fname = @au_fname
, phone = @phone, address = @address, city = @city, state = @state
, zip = @zip, contract = @contract
WHERE (au_id = @au_id)
END
COMMIT

> No lo recomendaria, pero poder se puede. La principal razon por la que
no me gusta, es que no puedo otorgar permisos espeficicos para
Insertar/Borrar/Actualizar de forma separada quitando un elemento

importante

de los Procedimientos que es seguridad.
2) Exactamente. Este fue durante mucho tiempo la "recomendacion

general"

en el sentido que permitia gran flexibilidad, seguridad y desempeno. Pero
con el tiempo y el desarrollo de n-capas ya no es "tan importante" la
seguridad en la base de datos sino que es una funcion de los componentes

de

capa media que brindan en estos servicios. En mi caso, me mantengo usando
procedimientos almacenado sobre todo por la independencia de las tabla,

pero

entiendo la posicion alterna.
3) Exactamente. Ese es para mi uno de los imporantes limitaciones de
este esquema, la generacion del codigo inicial. Debido a que Visual
Studio.NET hace facilisimo la generacion de codigo ya no es tan importante
la objeccion, es casi como que Visual Studio "sugiriera" usar este

esquema.

Sobre el SP, tal vez un procedimiento de Borrado (1/2 suicida) te

sirva

de ejemplo:
> CREATE PROCEDURE BorraAutoresConLibros(
@Accion as varchar(3)
, @au_id id
)
AS
BEGIN TRAN
DELETE sales
FROM Sales
JOIN titleauthor
ON Sales.Title_ID=TitleAuthor.Title_ID
WHERE TitleAuthor.Au_ID=@Au_Id

DELETE titleauthor
WHERE (au_id = @au_id)

DELETE authors
WHERE (au_id = @au_id)
COMMIT
> Espero te sirva,



Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"El principiante" wrote in message
news:
> > En cuanto al ejemplo: Si tienes un procedimiento que hace inserta

un

> > cheque, para que quieres un trigger? No seria mas facil tener todo el
> codigo
> > junto (funcionalmente agrupado) y de mas facil mantenimiento. Si

decides

> no
> > tener un Procedimiento de Cheques, tiene mucho sentido hacer un

Trigger.

>
> Oye Javier,
>
> 1) se podria configurar un SP unico que sea tanto para insertar como

para

> borrar o para actualizar una tabla ?
>
> 2) Cuando hablas de un procedimiento de Cheques para este ejemplo,

quieres

> decir que en vez de mandar un insert desde la aplicacion, lo que se haga
sea
> mandar llamar el procedimiento almacenado con los datos de las columnas
como
> parametros ?
>
> 3) Si uno decide usar sp para actualizaciones, implicaria entonces tener
un
> SP para cada tabla actualizable del sistema ?
>
> Finalmente) Podrias poner aqui (tu u otra persona del foro) algun

ejemplo

> de un SP que se utilice para insertar un registro y hacer algunas otras
> cosas posteriores (como se hace en un trigger) ?
>
>
> Gracias
> Andres Ledesma
>
>