SGBD & SQL - Quand utiliser SELECT *,
Un billet blog proposé par escartefigue
Le 19/04/2023, par escartefigue, Modérateur
On trouve très souvent des traitements dans lesquels les requêtes utilisent des ordres SELECT *.
Or il faut savoir que, avec SELECT *
Pour ces raisons, certaines entreprises interdisent purement et simplement de coder SELECT * dans un livrable !
Les seuls cas où l'on peut s'autoriser SELECT * sont les suivants :
Or il faut savoir que, avec SELECT *
- on transporte des colonnes dont on n'a pas besoin, ce qui charge le réseau inutilement et pénalise les performances :
- il est très rare qu'on ait besoin de toutes les colonnes d'une table dans un traitement,
- si la requête utilise des jointures, toutes les colonnes de jointure sont présentes plusieurs fois ; - les études d'impact sont difficiles puisqu'on ne sait pas quelles sont les colonnes réellement utiles au traitement ;
- en cas de modification de la table ou de la vue, le traitement plante ou les résultats sont erronés ;
- les index couvrants, si présents, sont inutilisables.
Pour ces raisons, certaines entreprises interdisent purement et simplement de coder SELECT * dans un livrable !
Les seuls cas où l'on peut s'autoriser SELECT * sont les suivants :
- requête jetable, exécutée à la volée, mais qui n'a pas vocation à être intégrée dans un livrable ;
- cas particulier du test d'existence avec (NOT) EXISTSEn effet, dans ce cas, le SELECT ne transporte qu'un booléen (vrai/faux), il n'y a donc pas d'inconvénient à coder SELECT *.
Toutefois, le risque subsiste qu'un développeur ne connaissant pas cette particularité copie/colle ce code pour un autre usage, retombant ainsi dans les travers évoqués plus haut.
C'est pourquoi, pour un test d'existence, je préfère coder SELECT 1 dans la requête corrélée.