Activador ANTES o DESPUÉS para mantener el registro de auditoría

Question

He estado leyendo el flujo de comentarios de MySql 5.0 en crear página de activación  y me gustaría preguntar a la comunidad si las recomendaciones son buenas & amp; Si todavía se aplican a 5.1. Lo que he notado al jugar con los activadores hoy es que es imposible actualizar un campo en la tabla anterior con un DESPUÉS DE ACTUALIZACIÓN.

1. Tenga cuidado con los disparadores ANTES. Pueden producirse restricciones, específicamente si está utilizando el motor InnoDB, donde fallará una inserción, pero las acciones de su desencadenante ANTES tendrán éxito.
2. Use BEFORE desencadena principalmente para restricciones o reglas, no para transacciones, ajustar las columnas NEW. * debería estar bien.
3. Manténgase con los activadores AFTER para la mayoría de las demás operaciones, como insertar en una tabla de historial o actualizar una desnormalización.

Answer 1

Sí. AFAIK, MySQL 5.1 no realizó ningún cambio en la semántica de cómo funcionan los activadores. MySQL intenta admitir la especificación ANSI / ISO SQL para la semántica de activación.

Puedes imaginar que hay una secuencia de operaciones que se ejecuta cuando se escribe una fila en la base de datos:

1. Ejecutar antes de los desencadenantes
2. Evalúe las restricciones, aplique NOT NULL , aplique DEFAULT valores
3. escriba la fila en la base de datos
4. Índices de actualización
5. Ejecutar después de los desencadenantes

Una vez que haya alcanzado el disparador AFTER, es demasiado tarde para cambiar los valores en la fila. En algunas bases de datos, puede establecer NEW.somecolumn = 1234 pero este cambio se descarta silenciosamente cuando finaliza el activador AFTER. En otras bases de datos, le ayuda a comprender su error, ya que le da un error cuando define el activador o cuando ejecuta el activador.

Los desencadenantes AFTER se utilizan mejor para acciones adicionales como resultado de INSERT / UPDATE de la fila, como el registro de auditoría que mencionó. Por un lado, MySQL solo permite un desencadenante por acción por tabla, por lo que si también está utilizando un desencadenante ANTES para cambiar los valores y hacer cumplir las reglas de negocios, ahora puede al menos mantener las acciones adicionales en un desencadenante separado. Eso hace que sea más fácil actualizar uno u otro.

La otra consideración es que probablemente debería realizar acciones adicionales solo después de que sepa que la fila se ha guardado correctamente. P.ej. no sería correcto registrar un cambio en un desencadenante BEFORE y luego cancelar el cambio debido a una restricción NOT NULL.

Para las acciones DELETE en las que necesita eliminar filas dependientes en otras tablas, es posible que aún tenga que hacer eso en un activador ANTES de.