ALTER TABLE Animal ADD CONSTRAINT fk_espece_id FOREIGN KEY
(espece_id) REFERENCES Espece (id);
ALTER TABLE Animal ADD CONSTRAINT fk_mere_id FOREIGN KEY (mere_id)
REFERENCES Animal (id) ON DELETE SET NULL;
ALTER TABLE Animal ADD CONSTRAINT fk_pere_id FOREIGN KEY (pere_id)
REFERENCES Animal (id) ON DELETE SET NULL;
Principe
Une transaction, c'est un ensemble de requêtes qui sont exécutées en un seul bloc. Ainsi, si une des requêtes du bloc échoue,
on peut décider d'annuler tout le bloc de requêtes (ou de quand même valider les requêtes qui ont réussi).
À quoi ça sert ?
Imaginez que Monsieur Durant fasse un virement de 300 euros à Monsieur Dupont via sa banque en ligne. Il remplit toutes les
petites cases du virement, puis valide. L'application de la banque commence à traiter le virement quand soudain, une violente
panne de courant provoque l'arrêt des serveurs de la banque.
Deux jours plus tard, Monsieur Durant reçoit un coup de fil de Monsieur Dupont, très énervé, qui lui demande pourquoi le
paiement convenu n'a toujours pas été fait. Intrigué, Monsieur Durant va vérifier son compte, et constate qu'il a bien été débité
de 300 euros.
Mais que s'est-il donc passé ?
Normalement, le traitement d'un virement est plutôt simple, deux étapes suffisent :
étape 1 : on retire le montant du virement du compte du donneur d'ordre ;
étape 2 : on ajoute le montant du virement au compte du bénéficiaire.
Seulement voilà, pas de chance pour Monsieur Durant, la panne de courant qui a éteint les serveurs est survenue pile entre
l'étape 1 et l'étape 2. Du coup, son compte a été débité, mais le compte de Monsieur Dupont n'a jamais été crédité.
La banque de Monsieur Durant n'utilisait pas les transactions. Si c'était le cas, la seconde requête du traitement n'ayant jamais
été exécutée, la première requête n'aurait jamais été validée.
Comment se déroule une transaction ?
Voici un schéma qui devrait vous éclairer sur le principe des transactions.
On démarre une transaction.
On exécute les requêtes désirées une à une.
Si une des requêtes échoue, on annule toutes les
requêtes, et on termine la transaction.
Par contre, si à la fin des requêtes, tout s'est bien passé,
on valide tous les changements, et on termine la
transaction.
Si le traitement est interrompu (entre deux requêtes par
exemple), les changements ne sont jamais validés, et
donc les données de la base restent les mêmes qu'avant
la transaction.
Partie 5 : Sécuriser et automatiser ses actions
221/414
www.openclassrooms.com
(espece_id) REFERENCES Espece (id);
ALTER TABLE Animal ADD CONSTRAINT fk_mere_id FOREIGN KEY (mere_id)
REFERENCES Animal (id) ON DELETE SET NULL;
ALTER TABLE Animal ADD CONSTRAINT fk_pere_id FOREIGN KEY (pere_id)
REFERENCES Animal (id) ON DELETE SET NULL;
Principe
Une transaction, c'est un ensemble de requêtes qui sont exécutées en un seul bloc. Ainsi, si une des requêtes du bloc échoue,
on peut décider d'annuler tout le bloc de requêtes (ou de quand même valider les requêtes qui ont réussi).
À quoi ça sert ?
Imaginez que Monsieur Durant fasse un virement de 300 euros à Monsieur Dupont via sa banque en ligne. Il remplit toutes les
petites cases du virement, puis valide. L'application de la banque commence à traiter le virement quand soudain, une violente
panne de courant provoque l'arrêt des serveurs de la banque.
Deux jours plus tard, Monsieur Durant reçoit un coup de fil de Monsieur Dupont, très énervé, qui lui demande pourquoi le
paiement convenu n'a toujours pas été fait. Intrigué, Monsieur Durant va vérifier son compte, et constate qu'il a bien été débité
de 300 euros.
Mais que s'est-il donc passé ?
Normalement, le traitement d'un virement est plutôt simple, deux étapes suffisent :
étape 1 : on retire le montant du virement du compte du donneur d'ordre ;
étape 2 : on ajoute le montant du virement au compte du bénéficiaire.
Seulement voilà, pas de chance pour Monsieur Durant, la panne de courant qui a éteint les serveurs est survenue pile entre
l'étape 1 et l'étape 2. Du coup, son compte a été débité, mais le compte de Monsieur Dupont n'a jamais été crédité.
La banque de Monsieur Durant n'utilisait pas les transactions. Si c'était le cas, la seconde requête du traitement n'ayant jamais
été exécutée, la première requête n'aurait jamais été validée.
Comment se déroule une transaction ?
Voici un schéma qui devrait vous éclairer sur le principe des transactions.
On démarre une transaction.
On exécute les requêtes désirées une à une.
Si une des requêtes échoue, on annule toutes les
requêtes, et on termine la transaction.
Par contre, si à la fin des requêtes, tout s'est bien passé,
on valide tous les changements, et on termine la
transaction.
Si le traitement est interrompu (entre deux requêtes par
exemple), les changements ne sont jamais validés, et
donc les données de la base restent les mêmes qu'avant
la transaction.
Partie 5 : Sécuriser et automatiser ses actions
221/414
www.openclassrooms.com