AVANT ou APRES déclencheur pour la maintenance du journal d'audit

Question

J'ai lu le flux de commentaires MySql 5.0 sur le create trigger page et je voudrais demander à la communauté si les recommandations sont bonnes & si elles s'appliquent encore à la version 5.1. Ce que j'ai remarqué en jouant avec des déclencheurs aujourd'hui, c'est qu'il est impossible de mettre à jour un champ dans l'ancienne table en utilisant AFTER UPDATE.

1. Soyez prudent avec les déclencheurs BEFORE. Des contraintes peuvent survenir, en particulier si vous utilisez le moteur InnoDB, où une insertion échouera, mais les actions de votre déclencheur BEFORE réussiront.
2. Utilisez les déclencheurs BEFORE principalement pour les contraintes ou les règles, et non pour les transactions. Il est préférable de modifier les colonnes NEW. *.
3. Coller avec les déclencheurs AFTER pour la plupart des autres opérations, telles que l'insertion dans une table d'historique ou la mise à jour d'une dénormalisation.

Answer 1

Oui. AFAIK, MySQL 5.1 n'a apporté aucune modification à la sémantique du fonctionnement des déclencheurs. MySQL essaie de prendre en charge la spécification SQL ANSI/ISO pour la sémantique de déclenchement.

Vous pouvez imaginer qu'il ya une séquence d'opérations qui fonctionne comme une ligne est écrite dans la base de données:

1. Run déclenche AVANT
2. Évaluer les contraintes, appliquer NOT NULL, appliquer DEFAULT valeurs
3. Écrivez la ligne à la base de données
4. index de mise à jour
5. Run déclenche APRÈS

Une fois que vous avez atteint le déclencheur AFTER, il est trop tard pour modifier les valeurs de la ligne. Dans certaines bases de données, vous pouvez définir NEW.somecolumn = 1234 mais cette modification est ignorée silencieusement lorsque le déclencheur AFTER se termine. Dans d'autres bases de données, cela vous aide à comprendre votre erreur en vous donnant une erreur soit lorsque vous définissez le déclencheur, soit lorsque vous exécutez le déclencheur.

Les déclencheurs AFTER sont mieux utilisés pour les actions supplémentaires à effectuer à la suite de INSERT/UPDATE de la ligne, tel que le journal d'audit que vous avez mentionné. D'une part, MySQL n'autorise qu'un seul déclenchement par action par table, donc si vous utilisez également un déclencheur BEFORE pour modifier des valeurs et appliquer des règles métier, vous pouvez au moins conserver les actions supplémentaires dans un déclencheur distinct. Cela rend plus facile la mise à jour de l'un ou l'autre.

L'autre considération est que vous devriez probablement faire des actions supplémentaires seulement après vous savez que la rangée a été enregistrée avec succès. Par exemple. il ne serait pas correct de consigner une modification dans un déclencheur BEFORE, puis d'annuler la modification en raison d'une contrainte NOT NULL.

Pour les actions DELETE dans lesquelles vous devez supprimer des lignes dépendantes dans d'autres tables, il se peut que vous deviez le faire dans un déclencheur BEFORE.