Le premier chapitre a déjà signalé que préciser les colonnes voulues reste souvent préférable à SELECT * dans une requête destinée à durer. Cette leçon détaille concrètement pourquoi, avec des exemples.

SELECT * FROM produits WHERE categorie = 'hygiene';

Si la table produits gagnait un jour une nouvelle colonne (par exemple, une description longue du produit), cette requête se mettrait à afficher cette nouvelle colonne automatiquement, sans que ce soit forcément voulu par la personne qui a écrit la requête à l'origine — un changement silencieux, difficile à repérer.

SELECT nom, prix FROM produits WHERE categorie = 'hygiene';

Cette version reste strictement stable face à l'ajout d'une colonne à la table : elle continue d'afficher exactement nom et prix, quoi qu'il arrive par ailleurs à la structure de la table.

SELECT * garde toute sa place pour une exploration rapide et ponctuelle d'une table (vu au premier chapitre) : le problème n'est pas SELECT * en lui-même, mais son usage dans une requête destinée à être réutilisée ou automatisée durablement.

À retenir :

• SELECT * dans une requête durable peut afficher silencieusement une colonne ajoutée plus tard à la table.
• Préciser les colonnes voulues protège une requête contre les changements futurs de structure de la table.

À vous de jouer : identifiez, parmi les requêtes déjà écrites dans ce module, celles qui gagneraient à remplacer un SELECT * par des colonnes précises.