On trouve très souvent des traitements dans lesquels les requêtes utilisent des ordres SELECT *.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.
Et si le SELECT est utilisé pour réaliser une insertion, en cas d'ajout de colonnes dans la table ou, c'est plus rare, de modification de l'ordre des colonnes, la requête devient invalide !
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.