Discussion :

[xanav]

J'ai pas mal cherché sur le net et on trouve du pour et du contre. Donc j'en appelle aux pros du SQL qui ont un retour d'expérience.

Ma question est la suivante : Lorsque des colonnes sont fonctionnellement liées et qu'on veut faire un group by, vaut-il mieux mettre tous les champs dans le group by ou faire une agrégation inutile ?

Concrètement laquelle de ces 2 requêtes sera la plus performante ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT CLI.CLI_ID, MIN(CLI.CLI_NOM), COUNT(CDE.CDE_ID) FROM CLIENT CLI
  JOIN COMMANDE CDE ON CDE.CLI_ID = CLI.CLI_ID
  GROUP BY CLI.CLI_ID

Ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT CLI.CLI_ID, CLI.CLI_NOM, COUNT(CDE.CDE_ID) FROM CLIENT CLI
  JOIN COMMANDE CDE ON CDE.CLI_ID = CLI.CLI_ID
  GROUP BY CLI.CLI_ID, CLI.CLI_NOM

Et je ne parle pas de MySQL, qui d'après ce que j'ai lu autorise de sélectionner des champs non groupés.
Personnellement, j'utilisais toujours la 1ère syntaxe mais aujourd'hui je me retrouve coincé avec un type bit sur lequel on ne peut pas faire de MIN ou MAX. Du coup, entre le mettre dans le group by ou faire un cast vers INT, pour faire un min puis refaire un cast faire bit, j'hésite...

[CinePhil]

C'est clairement la deuxième requête qui est à la fois la plus logique, la plus claire, la plus propre !

En lisant la première, je me suis demandé s'il n'y avait pas carrément une faute de frappe et que ce qui était recherché était la première commande du client par le plus petit id de commande associé au client !

En demandant au SGBD de chercher le MIN(CLI.CLI_NOM) pour un client, tu lui demandes du travail inutile puisqu'un client n'a qu'un seul nom !

[xanav]

Bah en fait, dans ma logique (qui n'est visiblement pas partagée de tous ) je me disais que dans les 2 cas, on fait travailler le SGBD pour rien :
- Soit on lui dit de calculer le minimum sur 1 valeur
- Soit on lui dit de regrouper suivant un champ qui ne possède toujours qu'une valeur pour le précédent regroupement.

Du coup je pensais que c'était peut-être plus rapide de calculer le minimum que de regrouper...
En fait, le plus logique (encore une fois, pour moi...) ça serait une fonction d’agrégation FIRST() qui prendrait la 1ère valeur trouvée sans se poser de question.

[CinePhil]

Il faudrait qu'un spécialiste du fonctionnement interne des SGBD réponde mais j'ose espérer que les développeurs de ceux-ci ont pensé à intégrer dans les algorithmes que le fait de regrouper sur une clé primaire (CLI_ID) implique de prendre sans se poser de question les valeurs des autres colonnes de la même table associées à la clé si elles sont demandées.
Donc, à mon avis, le SGBD ne fait pas d'opération de groupage sur CLI_NOM mais prend la valeur de CLI_NOM associée à la valeur de la clé CLI_ID sur laquelle il effectue le groupage.

S'il s'agit d'une requête de groupage avec jointure(s), je pense que le SGBD commence par joindre les tables, y appliquer les restrictions (WHERE) éventuelles puis fait le groupage sur le jeu de résultats.

Et comme, si je ne me trompe, le résultat d'une jointure entre deux relations (au sens théorie relationnelle) est une relation, le SGBD doit logiquement chercher la clé de cette relation résultante et procéder de la même manière que s'il n'y avait qu'une relation (table) dans la requête.

À confirmer par plus expert que moi sur ces sujets.

En fait, le plus logique (encore une fois, pour moi...) ça serait une fonction d’agrégation FIRST() qui prendrait la 1ère valeur trouvée sans se poser de question.

Ça c'est ce que fait le mauvais MySQL qui autorise de ne pas mettre dans le GROUP BY toutes les colonnes du SELECT ne faisant pas l'objet d'une fonction de groupage. Ainsi, MySQL autoriserait que ta requête ait ce groupage : GROUP BY CLI_ID avec le même SELECT.
Ça donnerait un résultat juste dans le cas de cette requête puisque CLI_NOM dépend directement de CLI_ID mais ça pourrait donner un résultat faux dans une requête avec jointure.

[SQLpro]

Tout dépend de l'optimiseur. Dans un SGBDR haut de gamme genre Oracle ou mieux SQL Server, l'optimiseur va récrire la requête au niveau de l'algébrisation afin de la simplifier. Ce n'est pas le cas par exemple de MySQL dont l'optimiseur est quasi inexistant... Quand à PG, de notables progrès sont encore à faire...

A +

[CinePhil]

Tout dépend de l'optimiseur. Dans un SGBDR haut de gamme genre Oracle ou mieux SQL Server, l'optimiseur va récrire la requête au niveau de l'algébrisation afin de la simplifier.

Tu veux dire que ces SGBD vont supprimer le MIN de la première requête de xanav ?

[xanav]

Effectivement, après quelque tests sur les temps de réponse sous SQL Server, il n'y a pas photo : Mettre le champ dans le GROUP BY est plus rapide que mettre un MIN().
Même sur une requête aussi simple que dans l'exemple, les temps de réponse sur mes tables sont les suivant :
- Requête 1 (avec le MIN) : environ 380 millisecondes
- Requête 2 (avec le GROUP BY) : environ 230 millisecondes

Et plus je rajoute de champs de la table client, plus l'écart augmente. En fait, le temps d'exécution de la requête 2 ne varie pas alors que l'autre augmente.

Petite précision : Il semblerait que sur une table qui ne possède pas de clé primaire (rhô !!! pas bien !!!) le résultat soit différent. Ça vaudrait donc le coup de tester avec un regroupement sur un champ qui ne soit pas forcément une clé...

Merci pour vos réponses, qui nous en apprennent un peu plus chaque jour.