procedimientos - trigger sql

¿Cuál es la diferencia entre disparadores, aserciones y controles(en la base de datos)?

Question

¿Alguien puede explicar (o sugerir un sitio o un documento) la diferencia exacta entre desencadenantes, aserciones y comprobaciones, y describir dónde debo usarlos?

EDITAR: Me refiero a la base de datos, no a ningún otro sistema o lenguaje de programación.

Answer 1

En el estándar SQL, tanto ASSERTIONS como CHECK CONSTRAINTS son lo que la teoría relacional llama "restricciones": reglas que los datos realmente contenidos en la base de datos deben cumplir.

La diferencia entre los dos es que las RESTRICCIONES DE COMPROBACIÓN son, en cierto sentido, mucho más "simples": son reglas que se relacionan con una sola fila, mientras que las ASERCIONES pueden involucrar cualquier número de otras tablas, o cualquier número de otras filas en la misma mesa. Eso, obviamente, lo hace (¡mucho más!) Más complejo para que los constructores de DBMS lo respalden, y esa es, a su vez, la razón por la que no lo hacen: simplemente no saben cómo hacerlo.

Los TRIGGERs son piezas de código ejecutable del cual se puede declarar al DBMS que deben ejecutarse cada vez que se realiza un cierto tipo de operación de actualización (insertar / eliminar / actualizar) en una tabla determinada. Debido a que los desencadenantes pueden generar excepciones, son un MEDIO para implementar lo mismo que una ASERCIÓN. Sin embargo, con los disparadores, aún es el programador el que tiene que hacer toda la codificación y no cometer errores.

EDITAR

Los comentarios de onedaywhen re. ASERCIÓN / COMPROBACIÓN cnstr. son correctos La diferencia es mucho más sutil (Y confusa). El estándar de hecho permite subconsultas en las restricciones CHECK. (Sin embargo, la mayoría de los productos no lo admiten, por lo que mi "relación con una sola fila" es cierta para la mayoría de los productos SQL, pero no para el estándar). Entonces, ¿todavía hay una diferencia? Sí todavía hay. Más de uno incluso.

Primer caso: TABLE MEN (ID: INTEGER) y TABLE WOMEN (ID: INTEGER). Ahora imagine una regla en el sentido de que "ningún valor de ID puede aparecer tanto en el MEN como en la tabla MUJER". Esa es una sola regla. La intención de ASSERTION es precisamente que el diseñador de la base de datos establezca esta única regla [y que se haga con ella], y el DBMS sabría cómo tratar esto [de manera eficiente, por supuesto] y cómo hacer cumplir esta regla, sin importar qué particular sea. actualización se realiza a la base de datos. En el ejemplo, el DBMS sabría que tiene que hacer una comprobación de esta regla en INSERT INTO MEN, y en INSERT INTO WOMEN, pero no en DELETE FROM MEN / WOMEN, o INSERT INTO en <anyothertable>.

Pero los DBMS no son lo suficientemente inteligentes para hacer todo eso. Pues, que hace falta hacer ? El diseñador de la base de datos debe agregar las restricciones DOS COMPROBACIONES a su base de datos, una a la tabla MEN (verificando los ID de MEN recién insertados contra la tabla MUJER) y otra a la tabla MUJER (verificando al revés). Hay su primera diferencia: una regla, una ASERCIÓN, DOS restricciones de VERIFICACIÓN. Las restricciones de CHECK son un nivel de abstracción más bajo que las ASSERTIONs, porque requieren que el diseñador piense más acerca de (a) todos los tipos de actualizaciones que podrían potencialmente violar su ASSERTION, y (b) qué cheque en particular debe llevarse a cabo para cualquiera de los "tipos de actualización" específicos que encontró en (a). (Aunque realmente no me gusta hacer afirmaciones "absolutas" sobre lo que sigue siendo "QUÉ" y lo que es "CÓMO", resumiría que las restricciones de VERIFICACIÓN requieren más pensamiento (procesal) de "CÓMO" por parte del diseñador de la base de datos, mientras que las ASERCIONES permitir que el diseñador de la base de datos se centre exclusivamente en el "QUÉ" (declarativo).

Segundo caso (aunque no estoy completamente seguro de esto, así que tome con un grano de sal): solo su regla de RI promedio. Por supuesto, está acostumbrado a especificar esto usando alguna cláusula de REFERENCIAS. Pero imagine que una cláusula de REFERENCIAS no estaba disponible. Una regla como "Cada ORDEN debe ser realizada por un CLIENTE conocido" es en realidad solo eso, una regla, por lo tanto: una sola ASERCIÓN. Sin embargo, todos sabemos que esta regla siempre puede violarse de dos maneras: insertando una ORDEN (en este ejemplo) y eliminando un CLIENTE. Ahora, en línea con el ejemplo anterior de HOMBRE / MUJER, si quisiéramos implementar esta regla única / ASERCIÓN utilizando las restricciones de VERIFICACIÓN, tendríamos que escribir una restricción de VERIFICACIÓN que verifique la existencia del CLIENTE luego de las inserciones en ORDER, pero la restricción de CHECK podría escribimos que hace lo que sea necesario al borrarlo del CLIENTE? Simplemente no están diseñados para ese propósito, por lo que puedo decir. Hay una segunda diferencia: las restricciones de CHECK están vinculadas exclusivamente a INSERTs, ASSERTIONS puede definir reglas que también se verifican al BORRAR.

Tercer caso: imagine una tabla COMPOS (componentID: ... porcentaje: INTEGER), y una regla a los efectos de que "la suma de todos los porcentajes debe ser igual en todo momento a 100". Esa es una regla única, y ASSERTION es capaz de especificar eso. Pero intente e imagine cómo aplicaría esa regla con las restricciones CHECK ... Si tiene una tabla válida con tres filas distintas de cero, por ejemplo, ¿cómo aplicaría cualquier cambio a esta tabla que pudiera sobrevivir? ¿Tu restricción CHECK? No puede eliminar o actualizar (disminuir) ninguna fila sin tener que agregar otras filas de reemplazo, o actualizar las filas restantes, que suman el mismo porcentaje. Igualmente para insertar o actualizar (aumentar). Necesitará por lo menos la verificación de restricciones diferidas, y luego, ¿qué va a COMPROBAR? Hay una tercera diferencia: las restricciones CHECK están dirigidas a filas individuales, mientras que ASSERTIONs también puede definir / expresar reglas que "abarcan" varias filas (es decir, reglas sobre agregaciones de filas).

Answer 2

La expresión debe ser verdadera para que se active el disparador, pero la verificación se evaluará siempre que la expresión sea falsa.

Answer 3

Las afirmaciones no modifican los datos, solo verifican ciertas condiciones.

Los disparadores son más potentes porque pueden verificar las condiciones y también modificar los datos.

-------------------------------------------------- ------------------------------

Las aserciones no están vinculadas a tablas específicas en la base de datos y no están vinculadas a eventos específicos

Los desencadenadores están vinculados a tablas específicas y eventos específicos

Answer 4

Una restricción de base de datos implica una condición que debe cumplirse cuando se actualiza la base de datos. En SQL, si una condición de restricción se evalúa como falsa, la actualización falla, los datos permanecen sin cambios y el DBMS genera un error.

Tanto CHECK como ASSERTION son restricciones de base de datos definidas por los estándares SQL. Una distinción importante es que un CHECK se aplica a una tabla base específica, mientras que un ASSERTION se aplica a toda la base de datos. Considere una restricción que limita las filas combinadas en las tablas T1 y T2 a un total de 10 filas, por ejemplo

CHECK (10 >= (
SELECT COUNT(*)
FROM (
SELECT *
FROM T1
UNION
SELECT *
FROM T2
) AS Tn
))

Supongamos que las tablas están vacías. Si esto se aplicara solo como una ASSERTION y un usuario intentara insertar 11 filas en T1 , la actualización fallaría. Lo mismo se aplicaría si la restricción se aplicara como una restricción CHECK solo a T1 . Sin embargo, si la restricción se aplicó como una restricción de CHECK a T2 solo la restricción tendría éxito porque una declaración dirigida a T1 no hace que se prueben las restricciones aplicadas a T1 .

Tanto ASSERTION como CHECK pueden diferirse (si se declaran como DEFERRABLE ), lo que permite que los datos infrinjan temporalmente la condición de restricción, pero solo dentro de una transacción.

ASSERTION restricciones ASSERTION y CHECK que implican subconsultas son características fuera de SQL estándar y ninguno de los principales productos de SQL admite estas características. MS Access (no es exactamente un producto de potencia industrial) admite restricciones CHECK que incluyen subconsultas pero no restricciones diferibles, además de que la prueba de restricciones siempre se realiza fila por fila, las consecuencias prácticas son que la funcionalidad es muy limitada.

En común con las restricciones CHECK , un disparador se aplica a una tabla específica. Por lo tanto, se puede usar un disparador para implementar la misma lógica que una restricción CHECK pero no una ASSERTION . Un disparador es un código de procedimiento y, a diferencia de las restricciones, el usuario debe asumir mucha más responsabilidad por preocupaciones como el rendimiento y el manejo de errores. La mayoría de los productos de SQL comerciales admiten desencadenantes (el acceso de MS Access mencionado anteriormente no).

Answer 5

Desencadenadores : un desencadenante es una pieza de SQL que se ejecuta antes o después de una actualización, inserción o eliminación en una base de datos. Un ejemplo de un activador en inglés simple podría ser algo así como: antes de actualizar un registro de cliente, guarde una copia del registro actual. Que se vería algo así como:

CREATE TRIGGER triggerName
AFTER UPDATE
INSERT INTO CustomerLog (blah, blah, blah)
SELECT blah, blah, blah FROM deleted

La diferencia entre aserciones y comprobaciones es un poco más turbia, muchas bases de datos ni siquiera admiten aserciones.

Restricción de verificación : una verificación es una pieza de SQL que se asegura de que se cumple una condición antes de que se pueda tomar acción en un registro. En un lenguaje sencillo, esto sería algo como: Todos los clientes deben tener un saldo de cuenta de al menos $ 100 en su cuenta. Que se vería algo así como:

ALTER TABLE accounts
ADD CONSTRAINT CK_minimumBalance
CHECK (balance >= 100)

Cualquier intento de insertar un valor en la columna de saldo inferior a 100 arrojaría un error.

Afirmaciones : una aserción es una pieza de SQL que se asegura de que se cumple una condición o impide que se realice una acción en un objeto de base de datos . Podría significar bloquear toda la tabla o incluso toda la base de datos.

Para que las cosas sean más confusas, se podría usar un desencadenante para imponer una restricción de verificación y en algunas bases de datos puede reemplazar una aserción (permitiéndole ejecutar código no relacionado con la tabla que se está modificando). Un error común para los principiantes es usar una restricción de verificación cuando se requiere un disparador o un disparador cuando se requiere una restricción de verificación.

Un ejemplo: Todos los clientes nuevos que abren una cuenta deben tener un saldo de $ 100; sin embargo, una vez que se abre la cuenta, su saldo puede caer por debajo de esa cantidad. En este caso, tiene que usar un disparador porque solo desea que se evalúe la condición cuando se inserta un nuevo registro.