TRIGGER O DISPARADOR

Un Disparador o Trigger es una rutina autnoma asociada con una tabla o vista
que automticamente realiza una accin cuando una fila en la tabla o la vista se
inserta (INSERT), se actualiza (UPDATE), o borra (DELETE). Un Disparador
nunca se llama directamente, en cambio, cuando una aplicacin o usuario intenta
insertar, actualizar, o anular una fila en una tabla, la accin definida en el
disparador se ejecuta automticamente (se dispara).

Las ventajas de usar los Disparadores son:
La entrada en vigor automtica de restricciones de los datos, hace que los
usuarios entren slo valores vlidos.
El mantenimiento de la aplicacin se reduce, los cambios a un disparador
se refleja automticamente en todas las aplicaciones que tienen que ver
con la tabla sin la necesidad de recompilar o relinquear.
Logs automticos de cambios a las tablas. Una aplicacin puede guardar
un registro corriente de cambios, creando un disparador que se active
siempre que una tabla se modifique.
La notificacin automtica de cambios a la Base de Datos con alertas de
evento en los disparadores.
Los Disparadores tienen dos palabras clave, OLD y NEW que se refieren a los
valores que tienen las columnas antes y despus de la modificacin. Los INSERT
permiten NEW, los DELETE slo OLD y los UPDATE ambas.
Un ejemplo de un disparador seria uno asociado a la sentencia DELETE en una
tabla de clientes, para impedir que se elimine uno que tenga un saldo distinto de
cero. Otro disparador seria guardar los datos que se modifican de un cliente en
otra base de datos que servira de auditoria.
VENTAJAS DE LOS TRIGGER
Seguridad de los datos mejorada
Ofrecen chequeos de seguridad basada en valores ,Integridad de los datos
mejorada
Fuerzan restricciones dinmicas de integridad de datos yde integridad
referencial.
Aseguran que las operaciones relacionadas se realizan juntas de forma implcita
Respuesta instantnea ante un evento auditado
Ofrece un mayor control sobre la B.D.

DESVENTAJAS
Hay que definir con anticipacin la tarea que realizara el trigger
Peligro de prdida en Reorganizaciones
Hay que programarlos para cada DBMS
Un Trigger nunca se llama directamente
Los triggers no se desarrollan pensando en un solo registro, los mismos deben
funcionar en conjunto con los datos ya que se disparan por operacin y no por
registro
Por funcionalidad, no hay que poner en uno solo las funciones de INSERT,
UPDATE y DELETE.
Utilizar moderadamente los triggers
No se pueden utilizar en tablas temporales.
Adems, la funcin puede ser utilizada para disparar distintas relaciones (estas
funciones son llamadas "general trigger funcions").
Como ejemplo de utilizacin de lo descrito, se puede hacer una funcin general
que toma como argumentos dos nombres de campo e inserta el nombre del
usuario y la fecha (timestamp) actuales en ellos. Esto permite, por ejemplo, utilizar
los triggers en los eventos INSERT para realizar un Guia del Programador de
PostgreSQL

CREATE TRIGGER <trigger name> <BEFORE|AFTER>
<INSERT|DELETE|UPDATE>
ON <relation name> FOR EACH <ROW|STATEMENT>
EXECUTE PROCEDURE <procedure name> (<function args>);
Triggers (disparadores) Pgina 1 de 2
http://lucas.hispalinux.es/Postgresql-es/web/navegable/programmer/triggers.html
20/10/2002
seguimiento automtico de la creacin de registros en una tabla de transacciones.
Se podra utilizar
tambin para registrar actualizaciones si es utilizado en un evento UPDATE.
Las funciones trigger retornan un rea de tuplas (HeapTuple) al ejecutor. Esto es
ignorado para
trigger lanzados tras (AFTER) una operacin INSERT, DELETE o UPDATE, pero
permite lo siguiente a los triggers BEFORE: - retornar NULL e ignorar la operacin
para la tupla actual (y de este modo la tupla no ser
insertada/actualizada/borrada); - devolver un puntero a otra tupla (solo en eventos
INSERT y UPDATE) que sern insertados (como la nueva versin de la tupla
actualizada en caso de UPDATE) en lugar de la tupla original.
Notar que no hay inicializacin por parte del CREATE TRIGGER handler. Esto
ser cambiado en el futuro. Adems, si ms de un trigger es definido para el
mismo evento en la misma relacin, el orden de ejecucin de los triggers es
impredecible. Esto puede ser cambiado en el futuro.
Si una funcin trigger ejecuta consultas SQL (utilizando SPI) entonces estas
funciones pueden disparar nuevos triggers. Esto es conocido como triggers en
cascada. No hay ninguna limitacin explicita en cuanto al nmero de niveles de
cascada.
Si un trigger es lanzado por un INSERT e inserta una nueva tupla en la misma
relacin, el trigger ser llamado de nuevo (por el nuevo INSERT). Actualmente, no
se proporciona ningn mecanismo de sincronizacin (etc) para estos casos pero
esto puede cambiar. Por el momento, existe una funcin llamada funny_dup17()
en los tests de regresin que utiliza algunas tcnicas para parar la recursividad
(cascada) en si misma.

EJEMPLOS DE TRIGGER
1.-
Triggers DML: INSTEAD OF
Los TRIGGERS de tipo Instead OF son TRIGGERS que se disparan en lugar de la
operacin que los produce, es decir, una operacin de borrado de registros con la
instruccin delete sobre una tabla que tiene un TRIGGER de tipo INSTEAD OF no
se llega a realizar realmente, sino que SQL Server 2005 cuando detecta esta
operacin invoca al TRIGGER que es el responsable de actuar sobre los registros
afectados, en el ejemplo que estamos siguiendo, el TRIGGER sera el
responsable de borrar los registros de la tabla que ha disparado el evento. Si el
TRIGGER no se encarga de esta tarea, el usuario tendr la sensacin de que SQL
Server no hace caso a sus comandos ya que por ejemplo una instruccin DELETE
no borrar los registros.

Como ejemplo de TRIGGER de tipo INSTEAD OF vamos a ver como se
implementara la siguiente regla: no se pueden borrar los clientes cuyo Crdito
Total sea mayor que cero, sin embargo si dentro de una operacin de borrado hay
clientes con Riesgo Total cero y otros con Riesgo Total distinto de cero, los que
tengan cero si deben resultar eliminados. El TRIGGER que implementara esa
regla sera el siguiente.
CREATE TRIGGER TR_BorradoSelectivo on Clientes INSTEAD OF DELETE
AS
BEGIN
DELETE c
FROM Clientes C
INNER JOIN DELETED d
ON C.idCliente=D.idCliente
WHERE C.CreditoTotal=0
END
2.-
Triggers DML: AFTER
Todos los TRIGGERS sirven en general para implementar restricciones de
negocio avanzadas, como ejemplo vamos a ver como se construira un TRIGGER
que impidiese que se aumentase el Crdito total de un cliente que tenga pagos
pendientes, para ello vamos a suponer una tabla de clientes con identificador
idCliente y con un campo llamado CreditoTotal y una tabla de recibos conteniendo
el idcliente y el estado del recibo (estos son solamente los campos que son
relevantes para nuestro ejemplo).
CREATE TRIGGER TR_CompruebaCreditoTotal ON Clientes AFTER UPDATE
AS
BEGIN
IF UPDATE(CreditoTotal)
-- Se est actualizando el campo crdito total, comprobemos
-- las restricciones.
BEGIN
IF EXISTS( SELECT IdCliente
FROM RECIBOS
WHERE Estado=PEN AND idCliente IN (SELECT idCliente FROM DELETED)
)
BEGIN
ROLLBACK -- Deshacemos la transaccin impidiendo que se actualize
RAISERROR (No se pueden actualizar el crdito de clientes con recibos
pendientes,16,1)
END
END
END

3.-
Triggers DDL: a nivel de base de datos
Los TRIGGERS DML (Data Manipulation Language) responden a la necesidad de
garantizar la integridad y consistencia de los datos dentro de nuestras tablas de
usuario, sin embargo no ayudan a mantener las reglas de diseo de nuestra base
de datos. El nombre coincide pero el propsito es distinto, los triggers DDL (Data
Definition Language) nos proporcionarn mecanismos para garantizar que nuestra
base de datos est diseada e implementada de acuerdo a los estndares que
hayamos definido.

Los TRIGGERS DDL tienen dos alcances diferenciados, a nivel de servidor y a
nivel de base de datos. Estos alcances estn enlazados con el tipo de evento que
los dispare, en esta primera parte los eventos que vamos a ver son a nivel de
Base de datos y algunos ejemplos de ellos son:
CREATE / ALTER /DROP View
CREATE / ALTER /DROP Table
CREATE / ALTER /DROP Schema

Aunque hay muchos ms, relacionados con estadsticas, sinnimos, usuarios (no
confundir con logins que son a nivel de servidor), procedimientos, etc. Puede
consultar los libros en pantalla de SQL Server 2005 para obtener una relacin
completa de todos los eventos a los que puede responder.

Los TRIGGERS DDL tiene una particularidad adicional sobre los de tipo DML y es
que no tiene mucho sentido las tablas inserted y deleted ya que el tipo de
operaciones que disparan los triggers son radicalmente diferentes. Sin embargo,
como ellos necesitan recibir informacin acerca del evento que ha ocasionado que
el trigger se dispare, para ello existe la funcin EVENTDATA(), esta funcin
devuelve un valor XML que responde al siguiente esquema:
<EVENT_INSTANCE>
<EventType>type</EventType>
<PostTime>date-time</PostTime>
<SPID>spid</ SPID>
<ServerName>name</ServerName>
<LoginName>name</LoginName>
<UserName>name</UserName>
<DatabaseName>name</DatabaseName>
<SchemaName>name</SchemaName>
<ObjectName>name</ObjectName>
<ObjectType>type</ObjectType>
<TSQLCommand>command</TSQLCommand>
</EVENT_INSTANCE>


PROCEDIMIENTOS ALMACENADOS

Los procedimientos almacenados y funciones son nuevas funcionalidades de la
versin de MySQL 5.0. Un procedimiento almacenado es un conjunto de
comandos SQL que pueden almacenarse en el servidor. Una vez que se hace, los
clientes no necesitan relanzar los comandos individuales pero pueden en su lugar
referirse al procedimiento almacenado.
Algunas situaciones en que los procedimientos almacenados pueden ser
particularmente tiles:
Cuando mltiples aplicaciones cliente se escriben en distintos lenguajes o
funcionan en distintas plataformas, pero necesitan realizar la misma
operacin en la base de datos.
Cuando la seguridad es muy importante. Los bancos, por ejemplo, usan
procedimientos almacenados para todas las operaciones comunes. Esto
proporciona un entorno seguro y consistente, y los procedimientos pueden
asegurar que cada operacin se loguea apropiadamente. En tal entorno, las
aplicaciones y los usuarios no obtendran ningn acceso directo a las tablas
de la base de datos, slo pueden ejectuar algunos procedimientos
almacenados.
Los procedimientos almacenados pueden mejorar el rendimiento ya que se
necesita enviar menos informacin entre el servidor y el cliente. El intercambio que
hay es que aumenta la carga del servidor de la base de datos ya que la mayora
del trabajo se realiza en la parte del servidor y no en el cliente. Considere esto si
muchas mquinas cliente (como servidores Web) se sirven a slo uno o pocos
servidores de bases de datos.