Discussion :

[Papy214]

Bonjour

Pour récupérer toutes les colonnes d'une table, quelle que soit le SGBD, quelle est à votre avis la meilleure syntaxe ?

select * from matable ?

select matable.* from matable ?

select matable.Champ1, matable.Champ2, matable.Champ3 from matable ?

autre ?

Papy !

[Antoun]

La meilleure de quel point de vue ?

[Papy214]

performance, rapidité

[Antoun]

Alors il vaut mieux éviter l'étoile et citer explicitement les colonnes (afin de ne pas obliger le SGBD à consulter son dictionnaire de données).

[CinePhil]

J'ajouterai à l'excellente réponse d'Antoun que le préfixage des noms de colonne par le nom ou l'alias de la table n'est utile qu'en cas d'une requête impliquant plusieurs tables. Dans ce cas c'est même très fortement recommandé car il peut y avoir confusion entre colonnes de même nom dans plusieurs tables (ça ne devrait pas exister à mon avis mais bon...).

[pacmann]

Salut !

@antoun : l'analyseur ne vérifie pas dans le dictionnaire lorsque tu lui précises les colonnes ?

[Antoun]

Salut !

@antoun : l'analyseur ne vérifie pas dans le dictionnaire lorsque tu lui précises les colonnes ?

Celui de quel SGBD ?

[pacmann]

Allez, au pif : Oracle !
De ce que j'imagine être les mécanismes d'accès, je vois mal comment il pourrait te renvoyer un résultat sans accéder à la description de la table d'une manière ou d'une autre...

[Antoun]

Comme j'ai moins d'imagination que toi, je ne peux que t'inviter à aller voir chez les oraclistes...

[SQLpro]

Extrait de mon blog :
Les 10 meilleures pratiques pour développer avec un SGBDR
http://blog.developpez.com/sqlpro?ti...s_sur_ms_sql_s

COMMANDEMENT N°3

Évitez impérativement "SELECT *"

Moins les données circulent, plus les temps d'exécution sont écourtés. Mieux vaut donc mettre dans la liste des colonnes uniquement celles nécessaires, pour ne pas renvoyer systématiquement tout.
Moins le serveur à d'effort à faire pour retrouver les informations dans les tables systèmes (nom et type des colonnes par exemple, mais aussi privilèges...) plus la préparation de la requête est écourtée.
Même si vous voulez renvoyer actuellement toutes les colonnes pour les afficher toutes, que ferez-vous si la table est remaniée ultérieurement notamment en ajoutant une colonne ? Le risque de voir votre code client ne plus fonctionner est assez important.

Mais il arrive parfois, et même de plus en plus, que le développeur de bonne foi, soit confronté à des SELECT * qu'il n'a pourtant pas demandé. Ce sont en général de merveilleux outils de développement, dont le choix a été fait « à la va-vite » et plus sur leur aspect que sur leurs qualités, qui en sont la cause. A l'heure du développement Web rapide, ce genre de chose est de plus en plus courant...

Le pire en ce domaine est l'utilisation d'Access en frontal de MS SQL Server. Ceux qui se sont contenté d'utiliser le RAD d'Access sans tenir compte de ce que faisait le moteur JET derrière ont dû avoir de très mauvaises surprises lors des montées en charge. Il y a quelques temps j'ai dû rendre un "arrêt de mort" sur un logiciel développé par un grand éditeur. Celui-ci avait été racheté à une petite boîte qui avait réalisé cela « à la va vite » avec Access et eût l'idée ingénieuse de porter cela en SQL Server à l'aide de 3 clics. Le résultat était particulièrement catastrophique. En effet Access a une conception curieuse de l'accès aux données : pour afficher une seule information, il fait un SELECT * sur la table et filtre sur le client. Imaginez le temps d'attente lorsque la table passe de 300 lignes à quelques centaines de milliers...

Seule exception à cette règle, les sous requêtes corrélées encapsulées par le prédicat EXISTS. Préférez lorsque cela est possible le SELECT *. SQL Server remplacera cette étoile par une constante quelconque la mieux calibrée pour pulser les performances. Mais sachez que cela n'est pas toujours possible... Tiens ... Dans quel cas ? Je vous y laisse réfléchir.

A +

[clementratel]

Bonjour,

+1 pour le fait d'éviter l'utilisation de SELECT *. En effet SELECT * signifie récupérer toutes les données de la table, or il est rare le cas où toutes les données de la table seront utiles. C'est donc, gain en performance évident mis à part, une question de pragmatisme. On ne récupère pas d'information inutile et on facilite ainsi la compréhension du code. SELECT * peut il est vrai affecter lourdement une application lors de son évolution mais pas toujours. SSIS, l'ETL de Microsoft s'y adaptant en signalant une màj nécessaire des métadonnées.

a+, =)
-=Clement=-

[Papy214]

Merci pour toutes ces précisions