une fonction d'agrégation (agissant sur n'importe quelle colonne).
Cette règle est d'ailleurs logique. Imaginez la requête suivante :
Code : SQL
SELECT nom_courant, COUNT(*) AS nb_animaux, date_naissance
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY nom_courant;
Que vient faire la date de naissance dans cette histoire ? Et surtout, quelle date de naissance espère-t-on sélectionner ? Chaque
ligne représente une espèce puisque l'on a regroupé les lignes sur la base de Espece.nom_courant. Donc date_naissance n'a
aucun sens par rapport aux groupes formés, une espèce n'ayant pas de date de naissance. Il en est de même pour les colonnes
sexe ou commentaires par exemple.
Qu'en est-il des colonnes Espece.id , Animal.espece_id , ou Espece.nom_latin ? En groupant sur le nom courant de l'espèce, ces
différentes colonnes ont un sens, et pourraient donc être utiles. Il a cependant été décidé que par sécurité, la sélection de
colonnes n'étant pas dans les critères de groupement serait interdite. Cela afin d'éviter les situations comme au-dessus, où les
colonnes sélectionnées n'ont aucun sens par rapport au groupement fait.
Par conséquent, si vous voulez afficher également l'id de l'espèce et son nom latin, il vous faudra grouper sur les trois colonnes :
Espece.nom_latin, Espece.nom_courant et Espece.id . Les groupes créés seront les mêmes qu'en groupant uniquement sur
Espece.nom_courant, mais votre requête respectera les standards SQL.
Code : SQL
SELECT Espece.id, nom_courant, nom_latin, COUNT(*) AS nb_animaux
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY nom_courant, Espece.id, nom_latin;
id
nom_courant
nom_latin
nb_animaux
2 Chat
Felis silvestris
20
1 Chien
Canis canis
21
4 Perroquet amazone Alipiopsitta xanthops 4
3 Tortue d'Hermann Testudo hermanni
15
Le cas MySQL
On ne le répétera jamais assez : MySQL est un SGBD extrêmement permissif. Dans certains cas, c'est bien pratique, mais c'est
toujours dangereux.
Et notamment en ce qui concerne GROUP BY, MySQL ne sera pas perturbé pour un sou si vous sélectionnez une colonne qui
n'est pas dans les critères de regroupement. Reprenons la requête qui sélectionne la colonne date_naissance alors que le
regroupement se fait sur la base de l'espece_id . J'insiste, cette requête ne respecte pas la norme SQL, et n'a aucun sens. La
plupart des SGBD vous renverront une erreur si vous tentez de l'exécuter.
Code : SQL
SELECT nom_courant, COUNT(*) AS nb_animaux, date_naissance
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY espece_id;
Partie 3 : Fonctions : nombres, chaînes et agrégats
178/414
www.openclassrooms.com
Cette règle est d'ailleurs logique. Imaginez la requête suivante :
Code : SQL
SELECT nom_courant, COUNT(*) AS nb_animaux, date_naissance
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY nom_courant;
Que vient faire la date de naissance dans cette histoire ? Et surtout, quelle date de naissance espère-t-on sélectionner ? Chaque
ligne représente une espèce puisque l'on a regroupé les lignes sur la base de Espece.nom_courant. Donc date_naissance n'a
aucun sens par rapport aux groupes formés, une espèce n'ayant pas de date de naissance. Il en est de même pour les colonnes
sexe ou commentaires par exemple.
Qu'en est-il des colonnes Espece.id , Animal.espece_id , ou Espece.nom_latin ? En groupant sur le nom courant de l'espèce, ces
différentes colonnes ont un sens, et pourraient donc être utiles. Il a cependant été décidé que par sécurité, la sélection de
colonnes n'étant pas dans les critères de groupement serait interdite. Cela afin d'éviter les situations comme au-dessus, où les
colonnes sélectionnées n'ont aucun sens par rapport au groupement fait.
Par conséquent, si vous voulez afficher également l'id de l'espèce et son nom latin, il vous faudra grouper sur les trois colonnes :
Espece.nom_latin, Espece.nom_courant et Espece.id . Les groupes créés seront les mêmes qu'en groupant uniquement sur
Espece.nom_courant, mais votre requête respectera les standards SQL.
Code : SQL
SELECT Espece.id, nom_courant, nom_latin, COUNT(*) AS nb_animaux
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY nom_courant, Espece.id, nom_latin;
id
nom_courant
nom_latin
nb_animaux
2 Chat
Felis silvestris
20
1 Chien
Canis canis
21
4 Perroquet amazone Alipiopsitta xanthops 4
3 Tortue d'Hermann Testudo hermanni
15
Le cas MySQL
On ne le répétera jamais assez : MySQL est un SGBD extrêmement permissif. Dans certains cas, c'est bien pratique, mais c'est
toujours dangereux.
Et notamment en ce qui concerne GROUP BY, MySQL ne sera pas perturbé pour un sou si vous sélectionnez une colonne qui
n'est pas dans les critères de regroupement. Reprenons la requête qui sélectionne la colonne date_naissance alors que le
regroupement se fait sur la base de l'espece_id . J'insiste, cette requête ne respecte pas la norme SQL, et n'a aucun sens. La
plupart des SGBD vous renverront une erreur si vous tentez de l'exécuter.
Code : SQL
SELECT nom_courant, COUNT(*) AS nb_animaux, date_naissance
FROM Animal
INNER JOIN Espece ON Animal.espece_id = Espece.id
GROUP BY espece_id;
Partie 3 : Fonctions : nombres, chaînes et agrégats
178/414
www.openclassrooms.com