Code : SQL
UPDATE Animal
SET commentaires = 'Petit pour son âge'
WHERE id = 10;
DELETE FROM Animal
WHERE id = 47;
SELECT id, sexe, date_naissance, nom, commentaires, espece_id
FROM Animal
WHERE id IN (10, 47);
SELECT id, nom, date_histo, utilisateur_histo, evenement_histo
FROM Animal_histo;
id sexe date_naissance
nom
commentaires
espece_id
10 M
2010-07-21 15:41:00 Bobo Petit pour son âge 1
id
nom
date_histo
utilisateur_histo evenement_histo
10 Bobo
2012-05-03 21:51:12 sdz@localhost
UPDATE
47 Scroupy 2012-05-03 21:51:12 sdz@localhost
DELETE
Quelques remarques sur l'historisation
Les deux systèmes d'historisation montrés dans ce cours ne sont que deux possibilités parmi des dizaines. Si vous pensez avoir
besoin d'un système de ce type, prenez le temps de réfléchir, et de vous renseigner sur les diverses possibilités qui s'offrent à
vous.
Dans certains systèmes, on combine les deux historisations que j'ai présentées.
Parfois, on ne conserve pas les lignes supprimées dans la table d'historisation, mais on utilise plutôt un système d'archive,
séparé de l'historisation.
Au-delà du modèle d'historisation que vous choisirez, les détails sont également modifiables. Voulez-vous garder toutes les
versions des données, ou les garder seulement pour une certaine période de temps ? Voulez-vous enregistrer l'utilisateur SQL ou
plutôt des utilisateurs créés pour votre application, découplés des utilisateurs SQL ?
Ne restez pas bloqués sur les exemples montrés dans ce cours (que ce soit pour l'historisation ou le reste), le monde est vaste !
Restrictions
Les restrictions sur les triggers sont malheureusement trop importantes pour qu'on puisse se permettre de ne pas les mentionner.
On peut espérer qu'une partie de ces restrictions soit levée dans une prochaine version de MySQL, mais en attendant, il est
nécessaire d'avoir celles-ci en tête.
Voici donc les principales.
Commandes interdites
Il est impossible de travailler avec des transactions à l'intérieur d'un trigger.
Cette restriction est nécessaire, puisque la requête ayant provoqué l'exécution du trigger pourrait très bien se trouver elle-même à
l'intérieur d'une transaction. Auquel cas, toute commande START TRANSACTION, COMMIT ou ROLLBACK interagirait avec
cette transaction, de manière intempestive.
Les requêtes préparées ne peuvent pas non plus être utilisées.
Enfin, on ne peut pas appeler n'importe quelle procédure à partir d'un trigger.
Les procédures appelées par un trigger ne peuvent pas envoyer d'informations au client MySQL. Par exemple, elles ne
peuvent pas exécuter un simple SELECT, qui produit un affichage dans le client (un SELECT...INTO par contre est
permis). Elles peuvent toutefois renvoyer des informations au trigger grâce à des paramètres OUT ou INOUT.
Les procédures appelées ne peuvent utiliser ni les transactions (START TRANSACTION, COMMIT ou ROLLBACK) ni
les requêtes préparées. C'est-à-dire qu'elles doivent respecter les restrictions des triggers.
Partie 5 : Sécuriser et automatiser ses actions
324/414
www.openclassrooms.com
UPDATE Animal
SET commentaires = 'Petit pour son âge'
WHERE id = 10;
DELETE FROM Animal
WHERE id = 47;
SELECT id, sexe, date_naissance, nom, commentaires, espece_id
FROM Animal
WHERE id IN (10, 47);
SELECT id, nom, date_histo, utilisateur_histo, evenement_histo
FROM Animal_histo;
id sexe date_naissance
nom
commentaires
espece_id
10 M
2010-07-21 15:41:00 Bobo Petit pour son âge 1
id
nom
date_histo
utilisateur_histo evenement_histo
10 Bobo
2012-05-03 21:51:12 sdz@localhost
UPDATE
47 Scroupy 2012-05-03 21:51:12 sdz@localhost
DELETE
Quelques remarques sur l'historisation
Les deux systèmes d'historisation montrés dans ce cours ne sont que deux possibilités parmi des dizaines. Si vous pensez avoir
besoin d'un système de ce type, prenez le temps de réfléchir, et de vous renseigner sur les diverses possibilités qui s'offrent à
vous.
Dans certains systèmes, on combine les deux historisations que j'ai présentées.
Parfois, on ne conserve pas les lignes supprimées dans la table d'historisation, mais on utilise plutôt un système d'archive,
séparé de l'historisation.
Au-delà du modèle d'historisation que vous choisirez, les détails sont également modifiables. Voulez-vous garder toutes les
versions des données, ou les garder seulement pour une certaine période de temps ? Voulez-vous enregistrer l'utilisateur SQL ou
plutôt des utilisateurs créés pour votre application, découplés des utilisateurs SQL ?
Ne restez pas bloqués sur les exemples montrés dans ce cours (que ce soit pour l'historisation ou le reste), le monde est vaste !
Restrictions
Les restrictions sur les triggers sont malheureusement trop importantes pour qu'on puisse se permettre de ne pas les mentionner.
On peut espérer qu'une partie de ces restrictions soit levée dans une prochaine version de MySQL, mais en attendant, il est
nécessaire d'avoir celles-ci en tête.
Voici donc les principales.
Commandes interdites
Il est impossible de travailler avec des transactions à l'intérieur d'un trigger.
Cette restriction est nécessaire, puisque la requête ayant provoqué l'exécution du trigger pourrait très bien se trouver elle-même à
l'intérieur d'une transaction. Auquel cas, toute commande START TRANSACTION, COMMIT ou ROLLBACK interagirait avec
cette transaction, de manière intempestive.
Les requêtes préparées ne peuvent pas non plus être utilisées.
Enfin, on ne peut pas appeler n'importe quelle procédure à partir d'un trigger.
Les procédures appelées par un trigger ne peuvent pas envoyer d'informations au client MySQL. Par exemple, elles ne
peuvent pas exécuter un simple SELECT, qui produit un affichage dans le client (un SELECT...INTO par contre est
permis). Elles peuvent toutefois renvoyer des informations au trigger grâce à des paramètres OUT ou INOUT.
Les procédures appelées ne peuvent utiliser ni les transactions (START TRANSACTION, COMMIT ou ROLLBACK) ni
les requêtes préparées. C'est-à-dire qu'elles doivent respecter les restrictions des triggers.
Partie 5 : Sécuriser et automatiser ses actions
324/414
www.openclassrooms.com