Revisamos de forma cada post en nuestra web con la meta de enseñarte en todo momento la información más veraz y certera.
Disparadores – un disparador es una parte 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 disparador en inglés simple podría ser algo como: antes de actualizar el registro de un 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 afirmaciones y comprobaciones es un poco más turbia, muchas bases de datos ni siquiera admiten afirmaciones.
Comprobar restricción – Una verificación es una parte de SQL que asegura que se cumple una condición antes de que se pueda tomar acción en un registro. En términos sencillos, esto sería algo así 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 de menos de 100 arrojaría un error.
Afirmaciones – Una aserción es una parte de SQL que asegura que se cumpla una condición o detiene la acción en un objeto de base de datos. Podría significar bloquear toda la tabla o incluso toda la base de datos.
Para hacer las cosas más confusas, se podría usar un disparador para imponer una restricción de verificación y, en algunas bases de datos, puede tomar el lugar de una aserción (al permitirle 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 activador o un activador 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, debe usar un disparador porque solo desea que se evalúe la condición cuando se inserta un nuevo registro.
En el estándar SQL, tanto ASERCIONES como VERIFICAR RESTRICCIONES 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 VERIFICACIÓN son, en cierto sentido, mucho más “simples”: son reglas que se relacionan con una sola fila solamente, 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 hace (¡mucho!) Más complejo para los constructores de DBMS soportarlo, y esa es, a su vez, la razón por la que no lo hacen: simplemente no saben cómo hacerlo.
Los TRIGGER son fragmentos de código ejecutable de los cuales 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 disparadores pueden generar excepciones, son un MEDIO para implementar lo mismo que una ASERCIÓN. Sin embargo, con los disparadores, sigue siendo el programador quien tiene que hacer toda la codificación y no cometer ningún error.
EDITAR
Los comentarios de Onedaywhen son. ASERCIÓN / COMPROBACIÓN cnstr. son correctos. La diferencia es mucho más sutil (Y confusa). De hecho, el estándar permite subconsultas en restricciones CHECK. (Sin embargo, la mayoría de los productos no lo admiten, por lo que mi “relación con una sola fila” es true para la mayoría de los productos SQL, pero no para el estándar). Entonces, ¿todavía hay alguna diferencia? Sí, todavía lo 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 la tabla HOMBRES como en la tabla MUJERES”. 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 [and be done with it], y el DBMS sabría cómo lidiar con esto [efficiently, of course] y cómo hacer cumplir esta regla, sin importar qué actualización particular se realice en la base de datos. En el ejemplo, el DBMS sabría que tiene que verificar esta regla al INSERT INTO MEN, y al INSERT INTO WOMEN, pero no al BORRAR DE HOMBRES / MUJERES, o INSERT INTO
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 DOS restricciones CHECK a su base de datos, una a la tabla MEN (verificando los ID de MEN recién insertados con la tabla WOMEN) y otra a la tabla WOMAN (verificando al revés). Ahí está tu primera diferencia: una regla, una afirmación, DOS COMPRUEBE las limitaciones. 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 en (a) todos los tipos de actualización que podrían causar que su ASSERTION sea violada, y (b) qué comprobación particular debería llevarse a cabo. en busca de cualquiera de los “tipos de actualización” específicos que encontró en (a). (Aunque realmente no me gusta hacer declaraciones “absolutas” sobre lo que sigue siendo “QUÉ” y qué es “CÓMO”, resumiría que las restricciones CHECK requieren más pensamiento de “CÓMO” (procedimental) por parte del diseñador de la base de datos, mientras que ASSERTIONs 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 tómelo 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 imagina que una cláusula REFERENCIAS no estuviera disponible. Una regla como “Cada PEDIDO debe ser realizado por un CLIENTE conocido” es realmente solo eso, una regla, por lo tanto: una sola ASERCIÓN. Sin embargo, todos sabemos que dicha regla siempre se puede violar de dos maneras: insertando un PEDIDO (en este ejemplo) y eliminando un CLIENTE. Ahora, de acuerdo con el ejemplo anterior de HOMBRE / MUJER, si quisiéramos implementar esta única regla / ASERCIÓN usando restricciones CHECK, entonces tendríamos que escribir una restricción CHECK que verifique la existencia del CLIENTE en inserciones en ORDER, pero qué restricción CHECK podría escribimos que hace lo que sea necesario sobre supresión del cliente ? Simplemente no están diseñados para ese propósito, por lo que yo sé. Ahí está su segunda diferencia: las restricciones CHECK están vinculadas exclusivamente a INSERT, ASSERTIONS puede definir reglas que también se comprobarán en DELETE.
Tercer caso: Imagine una tabla COMPOS (componenteID: … porcentaje: INTEGER), y una regla en el sentido de que “la suma de todos los porcentajes debe ser en todo momento igual a 100”. Esa es una sola regla, y una ASERCIÓN es capaz de especificar eso. Pero intente imaginar cómo haría para hacer cumplir dicha regla con restricciones CHECK … Si tiene una tabla válida con, digamos, tres filas distintas de cero que suman cien, ¿cómo aplicaría cualquier cambio a esta tabla que pudiera sobrevivir? su 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. Lo mismo para insertar o actualizar (aumentar). Necesitaría comprobar las restricciones diferidas como mínimo, y luego, ¿qué va a COMPROBAR? Existe la tercera diferencia: las restricciones CHECK están dirigidas a filas individuales, mientras que las ASSERTION también pueden definir / expresar reglas que “abarcan” varias filas (es decir, reglas sobre agregaciones de filas).
Las afirmaciones no modifican los datos, solo verifican determinadas condiciones
Los disparadores son más poderosos porque pueden verificar las condiciones y también modificar los datos
Las afirmaciones no están vinculadas a tablas específicas en la base de datos y no están vinculadas a eventos específicos
Los disparadores están vinculados a tablas específicas y eventos específicos
Si guardas alguna desconfianza o disposición de innovar nuestro noticia te proponemos dejar una anotación y con placer lo leeremos.