¿El estándar SQL especifica el orden de validación de la restricción y desencadena el disparo?

Question

Tengo curiosidad si puedo confiar en cualquier orden particular de validación de NOT NULL, FOREIGN KEY, UNIQUE, CHECK restricciones y BEFORE desencadenantes.

Por experiencia, sé que MySQL comprueba primero NOT NULL, luego inicia el disparador BEFORE, y luego comprueba las restricciones UNIQUE. Oracle comprueba NOT NULL después del desencadenador BEFORE (creo que SQLServer hace lo mismo, pero no lo recuerda). ¿El estándar dice algo sobre el pedido o depende completamente del proveedor de DB?

Answer 1

Ese comportamiento particular parece ser un bug in MySQL, y solo afecta a BEFORE INSERT activadores, mientras que BEFORE UPDATE activadores se comportan correctamente.

El standard (como vinculado en los comentarios de interrogación) ciertamente no lo explica explícitamente, pero definitivamente implicaba:

Para cada cambio de estado de SCi, j en TECI, el activadores anteriores activado por SCi, j se ejecutan antes de que cualquiera de sus eventos de activación surta efecto. Cuando los eventos desencadenantes surten efecto, cualquier desencadenador AFTER activado por se ejecuta los cambios de estado de TECi.

Un error NOT NULL debe ser parte de una (es decir, el evento de activación) INSERT o UPDATE. El estándar no debería necesitar especificar esto. Hay absolutamente sin punto para comprobar preventivamente las restricciones en un conjunto de cambios que no es final porque su activador BEFORE es capaz de resolver los errores y introduciendo los nuevos.

Resumen: En realidad, no es hasta el proveedor de base de datos debido a restricciones de comprobación después de un desencadenante anterior es siempre necesario.