IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

SGBD & SQL - Quand utiliser SELECT *,
Un billet blog proposé par escartefigue

Le , par escartefigue

0PARTAGES

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.


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) EXISTS
    En 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.

Une erreur dans cette actualité ? Signalez-nous-la !