IN() et GROUP_CONCAT() sont dans un bateau
Il m’arrive fréquemment d’avoir à sélectionner des lignes de données à partir d’un ou plusieurs critères. C’est le cas dès que l’on souhaite récupérer une liste. C’est également très pratique pour mettre à jour ces dites-lignes. Seulement voilà, des fois on pourrait éviter quelques boucles et quelques complications avec l’utilisation de deux fonctions magiques de MySQL : IN() et GROUP_CONCAT().
§Sélection optimisée avec IN()
IN()
devrait être utilisé dès lors que l’on a plusieurs critères sur un même colonne.
L’écriture suivante ne devrait pas apparaitre dans votre code :
1 |
|
A la place, il devrait y avoir ceci :
1 |
|
C’est une habitude à prendre car elle permettra d’automatiser bien des choses. Imaginez qu’on ne fasse plus cette sélection “en dur” mais à partir d’un tableau PHP. Trois façons d’écrire la requête, vous verrez vite laquelle sera la plus pratique à réutiliser :
1 |
|
Le gros avantage de la dernière méthode c’est le retraitement des données.
Il est facile et plus logique d’imploser et
d’exploser une chaine composée
de séparateurs virgule (ou autre caractère employé aux mêmes fins).
1 |
|
§Aggrégats avec GROUP_CONCAT()
Dans les exemples précédents, $tableau
était rempli “en dur”. Dans la vraie vie, ça ne se passe pas comme ça : on récupère des identifiants (clés et/ou index) pour valider les sélections. L’exemple basique : on veut mettre à jour une table de configuration avec les ID d’articles présents dans une ou plusieurs catégories.
1 |
|
C’est simple, propre et on se dit qu’on a bien bossé. Et pourtant, l’utilisation
de la fonction d’agrégation GROUP_CONCAT()
de MySQL nous épargnera quelques lignes.
On appréciera :
1 |
|
Bref, on a gagné une boucle (le while
), des lignes de résultats MySQL
(autant de ressources d’économisées) et un traitement PHP en moins (implode
).
Et devinez quoi ? Le résultat retourné par le GROUP_CONCAT
s’intègre très bien dans le … IN()
.