Ta première requête utile
What you'll learn
- écrire des requêtes avec une liste explicite de colonnes après
SELECTet un filtre de lignes avecWHERE - traduire une question métier en SQL selon l'itinéraire : entité →
FROM, contraintes →WHERE(avecAND), sortie →SELECT, ordre →ORDER BY - expliquer pourquoi
SELECT *est une mauvaise pratique dans les requêtes de - vérifier une requête en la reformulant à voix haute : si ta reformulation correspond à la question de départ, la requête est juste sur le fond
La carte est étudiée — et QUERY change les règles. Jusqu'ici, tu contemplais toute l'archive en touriste ; un archiviste travaille autrement. Sur l'holopanneau, tout s'éteint sauf une table, et une consigne apparaît : pose ta question de sorte que la réponse ne contienne pas une seule ligne de trop, ni une seule colonne inutile.
On choisit les colonnes et les lignes utiles
Tout prendre avec * est pratique pour une première rencontre, mais dans le vrai travail, c'est comme amener tout l'entrepôt à la caisse. En général, il te faut des champs précis : énumère-les, séparés par des virgules, après SELECT.
Pour les lignes, même principe : au lieu de prendre toute la vitrine, sélectionne uniquement le segment voulu avec WHERE. Par exemple, demandons à « Kotomarket » uniquement les produits de la catégorie Livres :
Choosing the columns and rows you need
Grabbing everything with * is convenient for a first look, but in real work it’s like hauling the entire warehouse up to the checkout. Usually you need specific fields: list them, comma-separated, after SELECT.
It’s the same with rows: instead of the whole storefront, pick only the segment you need via WHERE. For example, let’s ask Kotomarket for only the products in the Books category:
| name | price |
|---|---|
| SQL для профи | 1290.00 |
| Чистый код | 1490.00 |
| Алгоритмы на практике | 1690.00 |
De la question métier à la requête
Les vraies questions n'arrivent pas à l'archiviste en SQL : « quels livres coûtent moins de mille cinq cents ? », « qu'est-ce qui, en électronique, coûte plus de 5000 ? ». La traduction suit toujours le même itinéraire :
- Entité → table. De quoi parle la question : de produits, d'acheteurs, de commandes ? « Les livres à moins de 1500 », c'est une question sur les produits, donc
FROM products. - Contraintes → WHERE. Chaque condition de la question devient une condition de filtre distincte : la catégorie « Livres », le prix inférieur à 1500.
- Quoi montrer → SELECT. Que veut voir la personne dans la réponse ? Le nom et le prix — c'est ce que nous énumérons, le reste est du bruit.
- Forme de la réponse → ORDER BY. « Du moins cher au plus cher » — un tri par prix.
-- « Quels livres coûtent moins de 1500 et combien, du moins cher au plus cher ? »
SELECT name, price
FROM products
WHERE category = 'Книги' AND price < 1500
ORDER BY price;
Plusieurs conditions se relient par le mot AND — nous détaillerons les opérateurs de filtre au chapitre suivant.
Dernier réflexe du bon archiviste : lis la requête terminée à voix haute, comme une phrase. « Parmi les produits, prendre les livres à moins de 1500, montrer le nom et le prix, trier par prix » — si ta reformulation correspond à la question de départ, la requête est juste sur le fond. Si « toutes les colonnes » ou « toute la vitrine » réapparaît dans ta reformulation, reviens en arrière et resserre.
Interview question
Question d'entretien : pourquoi SELECT * est-il considéré comme une mauvaise pratique dans les requêtes de ?
Bonne réponse : d'abord, il ramène des données superflues : le réseau et la mémoire sont gaspillés sur des colonnes inutiles, et la base perd parfois la possibilité de répondre uniquement à partir de l'index (un index-only scan ; les index, c'est le Chapitre 10). Ensuite, c'est fragile : lorsqu'on ajoute ou renomme des colonnes, les rapports et le code qui comptent sur l'ensemble et l'ordre des colonnes peuvent casser. Une liste explicite de colonnes est le contrat de la requête ; SELECT * doit rester réservé à l'exploration interactive des données.
SELECT name FROM products WHERE category = 'Книги' ?The index has been read: you know what’s in the five tables and which threads stitch them together. QUERY dims the map, and the next clearance level lights up on the holopanel — the reading terminal.
QUERY: Remember the cardinal property of this place: the archive answers only well-formed questions. From the next clearance on, we learn to ask precisely.