CREATE TEMPORARY TABLE TMP_Adoption_chien
SELECT Animal.id AS animal_id, Animal.nom AS animal_nom,
Animal.date_naissance AS animal_naissance, Animal.sexe AS
animal_sexe, Animal.commentaires AS animal_commentaires,
Race.id AS race_id, Race.nom AS race_nom,
Client.id AS client_id, Client.nom AS client_nom, Client.prenom AS
client_prenom, Client.adresse AS client_adresse,
Client.code_postal AS client_code_postal, Client.ville AS
client_ville, Client.pays AS client_pays, Client.date_naissance AS
client_naissance,
Adoption.date_reservation AS adoption_reservation,
Adoption.date_adoption AS adoption_adoption, Adoption.prix
FROM Animal
LEFT JOIN Race ON Animal.race_id = Race.id
INNER JOIN Adoption ON Animal.id = Adoption.animal_id
INNER JOIN Client ON Client.id = Adoption.client_id
WHERE Animal.espece_id = 1;
Toutes les requêtes pour obtenir les statistiques et informations demandées pourront donc se faire directement sur
TMP_Adoption_chien, ce qui sera plus rapide que de refaire chaque fois une requête avec jointure(s).
Il peut bien sûr être intéressant d'ajouter des index sur les colonnes qui serviront souvent dans les requêtes.
Tests
Il arrive qu'on veuille tester l'effet des instructions, avant de les appliquer sur les données.
Pour cela, on peut par exemple utiliser les transactions, et annuler ou valider les requêtes selon que l'effet produit correspond à
ce qui était attendu ou non.
Une autre solution est d'utiliser les tables temporaires. On crée des tables temporaires contenant les données sur lesquelles on
veut faire des tests, on effectue les tests sur celles-ci, et une fois qu'on est satisfait du résultat, on applique les mêmes requêtes
aux vraies tables. Cette solution permet de ne pas risquer de valider inopinément des requêtes de test. Sans oublier qu'il n'est pas
toujours possible d'utiliser les transactions : si les tables sont de type MyISAM, les transactions ne sont pas disponibles. De
même, les transactions sont inutilisables si les tests comprennent des requêtes provoquant une validation implicite des
transactions.
Petite astuce : pour tester une série d'instructions à partir d'un fichier (en utilisant la commande SOURCE), il est
souvent plus simple de créer des tables temporaires ayant le même nom que les tables normales, qui seront ainsi
masquées. Il ne sera alors pas nécessaire de modifier le nom des tables dans les requêtes à exécuter par le fichier selon
qu'on est en phase de test ou non.
Sets de résultats et procédures stockées
Lorsque l'on crée une procédure stockée, on peut utiliser les paramètres OUT et INOUT pour récupérer les résultats de la
procédure. Mais ces paramètres ne peuvent contenir qu'un seul élément.
Que faire si l'on veut récupérer plusieurs lignes de résultats à partir d'une procédure stockée ?
On peut avoir besoin de récupérer le résultat d'une requête SELECT, ou une liste de valeurs calculées dans la procédure. Ou
encore, on peut vouloir passer un set de résultats d'une procédure stockée à une autre.
Une solution est d'utiliser une table temporaire pour stocker les résultats qu'on veut utiliser en dehors de la procédure.
Exemple : création par une procédure d'une table temporaire stockant les adoptions qui ne sont pas en ordre de paiement.
Code : SQL
DELIMITER |
CREATE PROCEDURE table_adoption_non_payee()
BEGIN
DROP TEMPORARY TABLE IF EXISTS Adoption_non_payee;
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
364/414
www.openclassrooms.com
SELECT Animal.id AS animal_id, Animal.nom AS animal_nom,
Animal.date_naissance AS animal_naissance, Animal.sexe AS
animal_sexe, Animal.commentaires AS animal_commentaires,
Race.id AS race_id, Race.nom AS race_nom,
Client.id AS client_id, Client.nom AS client_nom, Client.prenom AS
client_prenom, Client.adresse AS client_adresse,
Client.code_postal AS client_code_postal, Client.ville AS
client_ville, Client.pays AS client_pays, Client.date_naissance AS
client_naissance,
Adoption.date_reservation AS adoption_reservation,
Adoption.date_adoption AS adoption_adoption, Adoption.prix
FROM Animal
LEFT JOIN Race ON Animal.race_id = Race.id
INNER JOIN Adoption ON Animal.id = Adoption.animal_id
INNER JOIN Client ON Client.id = Adoption.client_id
WHERE Animal.espece_id = 1;
Toutes les requêtes pour obtenir les statistiques et informations demandées pourront donc se faire directement sur
TMP_Adoption_chien, ce qui sera plus rapide que de refaire chaque fois une requête avec jointure(s).
Il peut bien sûr être intéressant d'ajouter des index sur les colonnes qui serviront souvent dans les requêtes.
Tests
Il arrive qu'on veuille tester l'effet des instructions, avant de les appliquer sur les données.
Pour cela, on peut par exemple utiliser les transactions, et annuler ou valider les requêtes selon que l'effet produit correspond à
ce qui était attendu ou non.
Une autre solution est d'utiliser les tables temporaires. On crée des tables temporaires contenant les données sur lesquelles on
veut faire des tests, on effectue les tests sur celles-ci, et une fois qu'on est satisfait du résultat, on applique les mêmes requêtes
aux vraies tables. Cette solution permet de ne pas risquer de valider inopinément des requêtes de test. Sans oublier qu'il n'est pas
toujours possible d'utiliser les transactions : si les tables sont de type MyISAM, les transactions ne sont pas disponibles. De
même, les transactions sont inutilisables si les tests comprennent des requêtes provoquant une validation implicite des
transactions.
Petite astuce : pour tester une série d'instructions à partir d'un fichier (en utilisant la commande SOURCE), il est
souvent plus simple de créer des tables temporaires ayant le même nom que les tables normales, qui seront ainsi
masquées. Il ne sera alors pas nécessaire de modifier le nom des tables dans les requêtes à exécuter par le fichier selon
qu'on est en phase de test ou non.
Sets de résultats et procédures stockées
Lorsque l'on crée une procédure stockée, on peut utiliser les paramètres OUT et INOUT pour récupérer les résultats de la
procédure. Mais ces paramètres ne peuvent contenir qu'un seul élément.
Que faire si l'on veut récupérer plusieurs lignes de résultats à partir d'une procédure stockée ?
On peut avoir besoin de récupérer le résultat d'une requête SELECT, ou une liste de valeurs calculées dans la procédure. Ou
encore, on peut vouloir passer un set de résultats d'une procédure stockée à une autre.
Une solution est d'utiliser une table temporaire pour stocker les résultats qu'on veut utiliser en dehors de la procédure.
Exemple : création par une procédure d'une table temporaire stockant les adoptions qui ne sont pas en ordre de paiement.
Code : SQL
DELIMITER |
CREATE PROCEDURE table_adoption_non_payee()
BEGIN
DROP TEMPORARY TABLE IF EXISTS Adoption_non_payee;
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
364/414
www.openclassrooms.com