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

Question

J'ai lu le flux de commentaires MySql 5.0 sur créer une page de déclencheur  et je voudrais demander à la communauté si les recommandations sont bonnes & amp; si elles s'appliquent toujours à 5.1. Ce que j’ai remarqué aujourd’hui en jouant avec les déclencheurs, c’est qu’il est impossible de mettre à jour un champ de l’ancienne table à l’aide d’un AFTER UPDATE.

1. Soyez prudent avec les déclencheurs BEFORE. Des contraintes peuvent survenir, en particulier si vous utilisez le moteur InnoDB, où l'insertion échouera, mais où 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 convient de modifier les colonnes NEW. *.
3. Utilisez 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. D'après les informations dont je dispose, MySQL 5.1 n'a apporté aucune modification à la sémantique du fonctionnement des déclencheurs. MySQL essaie de supporter la spécification SQL ANSI / ISO pour la sémantique du déclencheur.

Vous pouvez imaginer qu'une séquence d'opérations s'exécute lorsqu'une ligne est écrite dans la base de données:

1. Exécuter AVANT les déclencheurs
2. Évaluer les contraintes, appliquer NOT NULL , appliquer des valeurs DEFAULT
3. Ecrivez la ligne dans la base de données
4. Mettre à jour les index
5. Exécuter APRÈS les déclencheurs

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 en mode silencieux à la fin du déclencheur AFTER. Dans d'autres bases de données, cela vous aide à comprendre votre erreur en vous donnant une erreur lorsque vous définissez le déclencheur ou lorsque vous l'exécutez.

Les déclencheurs AFTER sont mieux utilisés pour les actions supplémentaires à effectuer à la suite de INSERT / UPDATE de la ligne, telles que la journalisation d'audit que vous avez mentionnée. D'une part, MySQL n'autorise qu'un seul déclencheur par action et par table. Par conséquent, si vous utilisez également un déclencheur BEFORE pour modifier les valeurs et appliquer les règles de gestion, vous pouvez au moins conserver les actions supplémentaires dans un déclencheur séparé. Cela facilite la mise à jour de l’un ou de l’autre.

L'autre considération est que vous ne devriez probablement effectuer d'actions supplémentaires que après si vous savez que la ligne 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'abandonner la modification en raison d'une contrainte NOT NULL.

Pour les actions DELETE pour lesquelles vous devez supprimer des lignes dépendantes dans d'autres tables, vous devrez peut-être le faire dans un déclencheur BEFORE.