Requêtes SELECT en SQL : filtrer et trier

Une requête demande des données à une base de données. Une requête SELECT simple lit la table stockée sans la modifier. SELECT nomme les colonnes à afficher et FROM nomme la table à lire.

Les exemples de texte utilisent la comparaison d’égalité ordinaire, sensible à la casse, dans SQLite et PostgreSQL. Les réglages de collation peuvent modifier la comparaison et le tri du texte.

Deux tables pour travailler

La table employees contient les huit lignes suivantes. salary est le salaire annuel en dollars ; hire_date est du texte au format YYYY-MM-DD. NULL marque une valeur manquante.

La table products enregistre les prix en dollars et les stocks en unités dans l’entrepôt.

Lire la structure de la requête

SELECT city, first_name
FROM employees;

Le jeu de résultats est une autre table : huit lignes et deux colonnes, avec city en premier. Aucun filtre n’est présent, chaque employé fournit donc une ligne. SQL ne garantit aucun ordre des lignes tant que tu n’ajoutes pas ORDER BY.

SELECT * FROM products; affiche toutes les colonnes dans l’ordre défini par la table. L’astérisque est utile pour explorer. Dans une requête enregistrée, nommer les colonnes permet de cibler le résultat et évite qu’une colonne ajoutée à la table en modifie la structure.

Rendre la syntaxe lisible

Sépare les colonnes par des virgules, sans virgule finale avant FROM. Termine l’instruction par un point-virgule. Les mots-clés ne sont pas sensibles à la casse : select fonctionne, mais les majuscules permettent de repérer facilement les clauses. Les espaces et les retours à la ligne séparent les mots ; ils ne changent pas le sens de cette requête. Un commentaire -- se poursuit jusqu’à la fin de sa ligne.

Les noms doivent correspondre au schéma. Si frist_name provoque une erreur de colonne introuvable, compare son orthographe à celle de first_name. SQL standard utilise des guillemets doubles pour les noms qui contiennent des espaces ou des mots réservés, comme "order date". PostgreSQL convertit en minuscules les noms sans guillemets, tandis que "City" recherche exactement ce nom avec sa majuscule. MySQL utilise normalement des accents graves ; les guillemets doubles délimitent les noms dans son mode ANSI_QUOTES. SQL Server accepte aussi les crochets et accepte les guillemets doubles lorsque QUOTED_IDENTIFIER est activé, ce qui est le cas par défaut.

Une valeur répétée dans le résultat d’une requête est souvent utile. Plusieurs employés peuvent vivre dans la même ville et chacun doit tout de même avoir une ligne. Utilise DISTINCT lorsque la question demande des valeurs ou des combinaisons différentes.

Choisir ce qui compte comme doublon

SELECT DISTINCT city
FROM employees;

Le résultat contient Chicago, Denver et Boston, sans ordre garanti. Un simple SELECT city renverrait huit lignes, car chaque employé fournit une ville. L’ajout de DISTINCT réduit cet affichage à trois valeurs différentes. Les huit enregistrements des employés restent stockés.

La comparaison porte sur toutes les colonnes sélectionnées. Considère :

SELECT DISTINCT department, city
FROM employees;

Ana et Chloe fournissent toutes deux (Sales, Chicago) : cette paire apparaît donc une fois. Emma fournit (Sales, Denver), qui est différente et reste présente. Les autres paires sont (IT, Denver), (Marketing, Boston), (IT, Chicago), (NULL, Boston) et (Marketing, Chicago). Le résultat comporte sept lignes. Des services sont répétés, car un service associé à une autre ville forme une ligne de résultat différente.

Écris DISTINCT une seule fois, immédiatement après SELECT. Il s’applique à toute la ligne sélectionnée. Le placer entre des noms de colonnes, comme dans SELECT department, DISTINCT city, provoque une erreur de syntaxe.

Faire attention aux colonnes incluses

Si tu ajoutes employee_id aux colonnes sélectionnées, chaque ligne devient différente. SELECT DISTINCT employee_id, city FROM employees; renvoie toujours huit lignes : chaque identifiant est unique, même lorsque la ville se répète. Pour répondre à « Dans quelles villes y a-t-il des employés ? », sélectionne uniquement la ville. Pour répondre à « Quels employés vivent dans chaque ville ? », conserve les colonnes d’identification et attends-toi à des villes répétées.

Lors de cette suppression des doublons, les NULL répétés sont traités comme des doublons. SELECT DISTINCT department FROM employees; renvoie Sales, IT, Marketing et une ligne NULL. La ligne NULL indique qu’un service est manquant ; ce n’est pas un quatrième nom de service. Cette règle sur les doublons diffère de NULL = NULL, qui donne inconnu dans un filtre.

Les comparaisons de texte suivent une collation, c’est-à-dire les règles de la base de données pour comparer et ordonner le texte. Avec les comparaisons ordinaires sensibles à la casse utilisées dans ces exemples SQLite et PostgreSQL, Chicago et chicago sont des valeurs différentes. Une liste DISTINCT peut révéler une casse incohérente. Supprimer les répétitions de l’affichage ne corrige pas l’orthographe des données stockées.

Combiner DISTINCT avec une courte liste triée

SELECT DISTINCT city
FROM employees
ORDER BY city
LIMIT 2;

D’abord, les villes en double disparaissent. Ensuite, les trois villes sont triées. Enfin, deux lignes restent dans le résultat : Boston et Chicago, dans cet ordre. Appliquer d’abord la limite aux lignes des employés répondrait à une autre question.

Dans une requête DISTINCT, conserve les colonnes de tri dans la liste SELECT. PostgreSQL l’exige ; SQLite autorise certaines requêtes qui trient selon une colonne non sélectionnée, mais le choix entre différentes valeurs masquées rend leur ordre difficile à interpréter. Si un résultat contient des répétitions inattendues, examine les colonnes sélectionnées avant de décider si DISTINCT a sa place dans la requête.

La clause WHERE ne conserve une ligne que lorsque sa condition est vraie. Elle suit FROM et peut tester n’importe quelle colonne de la table, y compris une colonne que tu n’affiches pas.

Associer la formulation à l’opérateur

<> est l’écriture de « différent de » en SQL standard. Les cinq bases de données présentées ici acceptent aussi !=. Utilise un seul signe égal pour l’égalité. SQLite accepte ==, mais PostgreSQL refuse cette forme.

Examiner une ligne située sur une borne

SELECT first_name, salary
FROM employees
WHERE salary > 60000;

Ben a 71 000, Emma a 65 000 et Farid a 83 000. Ce sont les trois lignes qui remplissent la condition, sans ordre précisé. David gagne exactement 60 000. Sa ligne ne satisfait pas > 60000, car « plus de » exclut l’égalité.

Remplace uniquement l’opérateur par >=. David rejoint alors le résultat, qui compte quatre lignes. C’est la différence entre « au moins 60 000 » et « plus de 60 000 ». Pour vérifier une borne, demande-toi ce qui arrive à une valeur exactement égale au seuil ; des valeurs bien supérieures ne peuvent pas révéler cette erreur.

Pour « au plus 20,50 », un prix de 20,50 satisfait la condition et un prix de 20,51 ne la satisfait pas. Lorsqu’une demande donne une borne inférieure et une borne supérieure, vérifie chaque extrémité séparément avant de relier les tests.

Écrire les valeurs numériques comme des nombres

Utilise des chiffres sans ajout dans les conditions SQL : 60000, sans virgule de milliers ni symbole monétaire. Une virgule sépare les éléments SQL ; WHERE salary > 60,000 est une erreur de syntaxe. Les valeurs décimales utilisent un point, comme dans WHERE price < 20.50. Les salaires et les prix doivent figurer dans des colonnes numériques pour que les comparaisons tiennent compte de leur valeur numérique.

Un texte qui ressemble à un nombre suit les règles du texte lorsqu’il est comparé comme tel. La valeur textuelle '9' se classe après '10', car son premier caractère vient plus tard. Cela concerne les caractères et ne signifie pas que neuf est supérieur à dix. Lis le type de données de la colonne avant d’interpréter une comparaison inattendue.

Filtrer sans afficher la colonne testée

SELECT first_name
FROM employees
WHERE salary < 50000;

Chloe et Grace satisfont la condition. Leur salaire sert à tester les lignes, mais il est absent du résultat. Tu n’as pas besoin d’ajouter le salaire à SELECT pour que le filtre fonctionne. Lors de la vérification d’une requête, l’afficher temporairement peut t’aider à comprendre pourquoi chaque ligne a été retenue.

Une égalité sur une clé primaire permet de rechercher directement un enregistrement : WHERE employee_id = 6 trouve Farid. Une clé primaire identifie une ligne ; cette égalité ne peut donc pas renvoyer plusieurs employés ayant le même identifiant.

Les données manquantes demandent une attention particulière. WHERE stock <> 0 renvoie six produits. Lamp Shade est exclu, car son stock connu est nul. Bookshelf est également exclu : son stock est NULL, donc la comparaison est inconnue et WHERE ne conserve pas la ligne. Un test « différent de » n’ajoute pas les valeurs manquantes à son résultat.

Les conditions sur le texte et les dates nécessitent des valeurs sous une forme que la base de données peut interpréter. Une valeur mal orthographiée peut ne renvoyer aucune ligne sans avertissement, tandis qu’une apostrophe manquante peut transformer cette valeur en nom de colonne.

Distinguer une valeur d’un nom

SELECT first_name
FROM employees
WHERE city = 'Chicago';

Les apostrophes font de 'Chicago' une valeur textuelle. Le résultat contient Ana, Chloe, Farid et Hugo. Sans apostrophes, Chicago est lu comme un nom : la base de données recherche donc une colonne portant ce nom. En SQL standard, les guillemets doubles délimitent aussi des noms. PostgreSQL refuse city = "Chicago" lorsqu’une telle colonne n’existe pas. Certaines configurations SQLite acceptent les chaînes entre guillemets doubles par compatibilité avec d’anciens usages ; utilise systématiquement des apostrophes pour les valeurs.

Une apostrophe à l’intérieur d’une valeur est doublée :

SELECT first_name
FROM employees
WHERE last_name = 'O''Neill';

Cette requête trouve Hugo. Les deux apostrophes consécutives représentent une apostrophe à l’intérieur de la valeur ; les apostrophes extérieures en marquent le début et la fin. SQL standard n’utilise pas de barre oblique inverse pour échapper cette apostrophe.

Vérifier les règles de comparaison

Une collation détermine l’égalité et le tri du texte, notamment le traitement de la casse et des lettres accentuées. Dans les comparaisons ordinaires sensibles à la casse de SQLite et PostgreSQL utilisées ici, 'Chicago' et 'chicago' sont différents. WHERE city = 'chicago' ne renvoie aucune ligne. MySQL et SQL Server utilisent souvent des collations insensibles à la casse ; leurs réglages habituels peuvent donc trouver les deux écritures.

Les comparaisons de plages de texte suivent aussi la collation. Avec ces noms, WHERE last_name < 'M' renvoie Brown, Carter, Haddad, Kim et Lopez. Les valeurs sont comparées à partir de la gauche. Une valeur plus longue qui commence par les mêmes caractères vient après son préfixe : 'Martin' vient après 'M'. Une limite fixée à 'M' n’équivaut pas à « tous les noms commençant par M ».

Placer l’année en premier

La colonne hire_date de l’exemple stocke des dates complètes sous forme de texte : année, mois, puis jour, avec des largeurs fixes. L’ordre du texte correspond ainsi à l’ordre chronologique.

SELECT first_name, hire_date
FROM employees
WHERE hire_date >= '2022-01-01';

Chloe, Grace et Hugo satisfont la condition. PostgreSQL possède aussi un véritable type DATE qui accepte ce littéral. Sa forme standard avec indication du type est DATE '2022-01-01' ; SQLite n’utilise pas cette syntaxe de littéral typé.

Une date dans un format local comme '03/04/2024' est ambiguë dans une colonne de dates, car les réglages peuvent en faire le 4 mars ou le 3 avril. Stockées sous forme de texte, les dates qui commencent par le mois sont comparées par mois avant l’année. Par exemple, '12/01/2021' se classe après '03/15/2024', alors que la première date est chronologiquement antérieure.

Traduire la borne avec une date complète

« Embauché après 2022 » signifie à partir du '2023-01-01'. Comparer le texte à '2022' admet aussi la date de Hugo, '2022-08-05' : le texte plus long se classe après le préfixe correspondant.

Si une colonne contient des heures, l’égalité avec une date seule ne sélectionne pas toutes les heures de cette journée. Pour inclure le 31 mars 2024, utilise ordered_at >= '2024-03-31' AND ordered_at < '2024-04-01'. Cela conserve toutes les heures à partir du début du 31 mars jusqu’au début du 1er avril, exclu.

Une ligne peut devoir satisfaire plusieurs tests. AND exige que les deux conditions soient vraies. OR exige qu’au moins une soit vraie. NOT inverse vrai et faux ; lorsqu’une condition est inconnue à cause de NULL, NOT la laisse inconnue.

Déterminer si les deux tests doivent être satisfaits

SELECT first_name
FROM employees
WHERE department = 'Sales' AND city = 'Chicago';

Ana et Chloe satisfont les deux tests. Emma travaille dans Sales mais vit à Denver : elle ne satisfait donc pas cette condition AND. Remplacer AND par OR admet aussi Emma, Farid et Hugo : les cinq employés retenus satisfont l’un des tests ou les deux.

Ajouter une condition AND peut laisser le résultat inchangé ou le réduire. Ajouter une condition OR peut le laisser inchangé ou l’élargir. Cela te permet de vérifier rapidement un filtre construit par étapes.

Chaque comparaison doit être complète. Écris department = 'IT' OR department = 'Marketing', en répétant la colonne et l’opérateur. department = 'IT' OR 'Marketing' n’exprime pas la deuxième comparaison. PostgreSQL le refuse ; SQLite traite le texte seul comme faux et ne renvoie que le personnel de IT. De même, écris salary > 50000 AND salary < 70000, avec le salaire des deux côtés de AND.

Traduire des groupes de possibilités

« Les employés de Boston et de Denver » désigne généralement les personnes de l’une ou l’autre ville. Chaque ligne ne contient qu’une ville : utilise donc city = 'Boston' OR city = 'Denver'. Cette condition renvoie Ben, David, Emma et Grace. Un AND entre ces égalités exige qu’une même valeur de ville désigne les deux lieux à la fois et ne renvoie aucune ligne.

Lorsque les opérateurs sont mélangés, NOT est évalué avant AND, et AND avant OR. Sans parenthèses :

WHERE department = 'Sales'
   OR department = 'Marketing' AND city = 'Chicago'

Cela désigne le personnel de Sales, quelle que soit sa ville, ainsi que le personnel de Marketing à Chicago. Emma satisfait la condition, car la comparaison avec Sales suffit. Pour limiter les deux services à Chicago, regroupe les possibilités :

SELECT first_name
FROM employees
WHERE (department = 'Sales' OR department = 'Marketing')
  AND city = 'Chicago';

Ana, Chloe et Hugo satisfont maintenant la condition. Les parenthèses soumettent les deux choix de service à une même exigence concernant la ville. Utilise-les pour clarifier un filtre qui mélange AND et OR, même lorsque l’ordre par défaut convient déjà.

Inverser tout un groupe

NOT (city = 'Chicago' OR city = 'Denver') renvoie David et Grace à Boston. Aucune des villes indiquées n’est acceptée. Pour ces valeurs, cette condition équivaut à city <> 'Chicago' AND city <> 'Denver'.

Utiliser OR entre ces deux tests « différent de » est un piège courant. Une ligne de Chicago diffère de Denver et une ligne de Denver diffère de Chicago. Chaque employé dont la ville est enregistrée satisfait au moins un des tests : le OR n’exclut donc aucune des deux villes.

Construis une condition complexe étape par étape. Vérifie les lignes après le premier test, puis après l’ajout du suivant. Tu peux inverser les deux côtés d’un AND ou les deux côtés d’un OR sans changer la réponse ; choisis la disposition qui rend les groupes les plus faciles à lire.

Utilise IN lorsqu’une colonne peut correspondre à l’une des valeurs d’une liste. Il raccourcit un groupe d’égalités reliées par OR tout en conservant leur sens.

Construire une liste de possibilités

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing');

Ben, David, Farid et Hugo satisfont la condition. Chacun a l’une des deux valeurs de service. Le même test pourrait s’écrire department = 'IT' OR department = 'Marketing'.

Place les éléments de la liste entre parenthèses, séparés par des virgules. Mets le texte entre apostrophes ; laisse les valeurs numériques sans apostrophes. Par exemple, employee_id IN (2, 4, 6) sélectionne Ben, David et Farid. L’ordre des éléments de la liste ne trie pas le résultat. Répéter un élément ne répète pas une ligne correspondante : IN (6, 2, 2, 4) sélectionne les mêmes enregistrements. Utilise ORDER BY si tu as besoin d’ordonner le résultat.

IN compare des valeurs entières selon les mêmes règles que l’égalité. city IN ('Chi') ne correspond pas à Chicago. Avec les comparaisons ordinaires sensibles à la casse utilisées ici, city IN ('chicago') ne lui correspond pas non plus. La recherche d’un fragment nécessite LIKE, tandis que le traitement de la casse dépend de la collation.

Appliquer une autre règle à chaque choix

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing')
  AND city = 'Chicago';

Farid et Hugo satisfont la condition. IN est une seule condition, donc AND applique le test sur la ville à tout le choix de services. Dans la version développée avec OR, mets les deux comparaisons de service entre parenthèses. Sans elles, department = 'IT' OR department = 'Marketing' AND city = 'Chicago' admet aussi Ben, car AND est prioritaire et la règle sur la ville ne s’applique qu’à Marketing.

Exclure les valeurs de la liste

WHERE city NOT IN ('Chicago', 'Denver') renvoie David et Grace. Une ville enregistrée ne satisfait la condition que si elle diffère des deux éléments. Cette forme est utile pour plusieurs exclusions et évite l’erreur qui consiste à relier des conditions « différent de » avec OR.

Les valeurs manquantes ne satisfont aucune des deux formes. Le service de Grace est NULL, donc department NOT IN ('Sales') ne l’inclut pas. La base de données ne peut pas établir que le service manquant diffère de Sales. Pour inclure aussi le personnel sans service attribué, écris department NOT IN ('Sales') OR department IS NULL.

Un NULL dans une liste NOT IN crée un problème plus large. department NOT IN ('Sales', NULL) exige à la fois department <> 'Sales' et department <> NULL. La deuxième comparaison est toujours inconnue, donc le test combiné n’est jamais vrai et WHERE ne renvoie aucune ligne. Sépare les tests de valeurs manquantes de la liste de valeurs.

Avec IN, une correspondance réelle réussit toujours même si un autre élément de la liste est NULL. department IN ('Sales', NULL) conserve les trois membres du personnel de Sales, mais n’ajoute pas Grace. Utilise IS NULL pour demander explicitement les valeurs manquantes.

Une liste IN ordinaire en SQL doit contenir au moins un élément. PostgreSQL refuse IN () ; SQLite l’accepte comme faux. Si un programme construit une liste à partir des choix de l’utilisateur, traite le cas d’une liste vide avant d’envoyer la requête afin que le comportement soit voulu dans toutes les bases de données.

BETWEEN teste une plage dont les deux bornes sont incluses. Utilise-le lorsque « de » et « à » incluent les valeurs limites indiquées ; utilise des comparaisons explicites lorsqu’une borne doit être exclue.

Vérifier les deux bornes

SELECT name, price
FROM products
WHERE price BETWEEN 15.50 AND 89.00;

Desk Lamp, Floor Lamp, Lamp Shade et Desk Organizer satisfont la condition. Floor Lamp coûte exactement 89,00 et Lamp Shade exactement 15,50 : les deux sont donc conservés. La condition signifie price >= 15.50 AND price <= 89.00.

Place la borne inférieure en premier. price BETWEEN 89.00 AND 15.50 demande un prix d’au moins 89,00 et d’au plus 15,50. La syntaxe est valide, mais aucune valeur ne correspond. BETWEEN ordinaire ne remet pas les bornes dans l’ordre pour toi. PostgreSQL propose BETWEEN SYMMETRIC pour le faire, mais utilise la forme avec la borne inférieure en premier pour une requête partagée avec SQLite.

Pour « plus de 15,50 et moins de 89,00 », écris price > 15.50 AND price < 89.00. Seuls Desk Lamp et Desk Organizer satisfont la condition. Cette différence concerne les bornes de la question, pas la façon dont le résultat est affiché.

À l’extérieur d’une plage

price NOT BETWEEN 20 AND 100 signifie price < 20 OR price > 100. Cette condition renvoie Lamp Shade, Office Chair, Standing Desk, Desk Organizer, Bookshelf et Paper Tray. Des valeurs égales à 20 ou à 100 seraient à l’intérieur de la plage initiale et ne satisferaient pas NOT BETWEEN.

Pour une valeur testée manquante, le résultat de chacun des deux tests est inconnu. Pour le stock, BETWEEN 5 AND 40 sélectionne cinq produits et NOT BETWEEN en sélectionne deux : Lamp Shade avec 0 et Desk Organizer avec 60. Le stock de Bookshelf est NULL et ne figure dans aucun des deux résultats. Une plage et sa négation ne couvrent donc pas nécessairement toutes les lignes stockées.

Dates et heures

Les dates complètes sous forme de texte dans l’ordre YYYY-MM-DD permettent de définir des plages de dates. hire_date BETWEEN '2020-01-01' AND '2022-12-31' sélectionne Ben, David et Hugo, en couvrant les trois années civiles dans cette colonne qui contient uniquement des dates.

Une colonne contenant des heures nécessite une autre borne supérieure pour couvrir un mois entier. Dans une colonne d’horodatage, une borne contenant seulement une date signifie minuit au début de ce jour. Sous forme de texte, même '2024-03-31 00:00:00' se classe après le préfixe plus court '2024-03-31'. Pour inclure toutes les heures de mars, utilise :

WHERE ordered_at >= '2024-03-01'
  AND ordered_at < '2024-04-01'

Cette condition inclut le début de mars et s’arrête juste avant avril, sans avoir à deviner la dernière fraction de seconde du 31 mars.

Plages de texte et deux usages de AND

Les bornes textuelles sont des valeurs complètes. last_name BETWEEN 'A' AND 'C' inclut Brown mais exclut Carter, puisque Carter se classe après son préfixe C. Selon ces règles de texte, last_name >= 'A' AND last_name < 'D' couvre les noms commençant par A, B ou C et renvoie Brown et Carter.

Dans price BETWEEN 10 AND 100 AND category = 'Lighting', le premier AND sépare les bornes de la plage ; le second relie le test de plage au test de catégorie. Les produits correspondants sont Desk Lamp, Floor Lamp et Lamp Shade. Des retours à la ligne peuvent rendre les deux rôles plus visibles.

LIKE compare du texte à un motif. Utilise-le pour rechercher un début, une fin ou un fragment lorsque l’égalité exigerait une valeur entière exacte.

Placer les caractères génériques

Le motif doit correspondre à la valeur entière. % peut représenter zéro caractère ou plus, y compris des espaces. Dans '%Lamp%', chaque signe pourcentage peut correspondre à une chaîne vide : le texte peut donc commencer ou se terminer par Lamp, mais aussi le contenir au milieu.

_ représente exactement un caractère. last_name LIKE '_im' trouve Kim. Les quatre tirets bas de first_name LIKE '____' trouvent Emma et Hugo, les prénoms qui comptent exactement quatre lettres. Le tiret bas ne représente pas un caractère facultatif.

SELECT first_name, phone
FROM employees
WHERE phone LIKE '312-%';

Ana, Chloe et Farid satisfont la condition, car leur numéro de téléphone enregistré commence par 312-. Le signe pourcentage couvre tous les caractères restants.

Choisir l’opérateur et la règle de casse

Les caractères génériques appartiennent aux motifs LIKE. name = '%Lamp%' recherche des signes pourcentage littéraux et ne renvoie ici aucun produit. Les caractères génériques * et ? utilisés dans la recherche de fichiers n’ont pas de signification particulière dans LIKE ; name LIKE 'Desk*' recherche un astérisque littéral après Desk.

LIKE dans SQLite ignore normalement la casse pour les lettres ASCII de A à Z, tandis que LIKE ordinaire dans PostgreSQL y est sensible. name LIKE '%desk%' trouve donc Desk Lamp, Standing Desk et Desk Organizer dans SQLite, mais aucun produit dans PostgreSQL avec une collation sensible à la casse. PostgreSQL propose aussi ILIKE, qui est insensible à la casse. Dans MySQL, le comportement suit la collation.

Pour les noms de produits ASCII utilisés ici, LOWER(name) LIKE '%desk%' donne les mêmes correspondances dans SQLite et PostgreSQL : LOWER convertit le nom en minuscules avant la recherche. Pour d’autres systèmes d’écriture, la conversion de casse dépend des règles de la base de données et de la langue. Dans SQLite, l’égalité diffère aussi de LIKE : city = 'chicago' ne trouve pas Chicago avec la collation binaire par défaut, alors que city LIKE 'chicago' le trouve.

Rechercher un véritable caractère générique

Pour rechercher un tiret bas littéral, choisis un caractère d’échappement :

WHERE code LIKE 'SPRING!_%' ESCAPE '!'

Dans une table de codes de réduction, ce motif correspond à 'SPRING_10' mais pas à 'SPRINGS10'. !_ représente un véritable tiret bas ; le dernier % correspond toujours à une séquence. Utilise la même méthode avec !% pour un signe pourcentage littéral. Écrire ESCAPE explicitement évite de dépendre des valeurs par défaut de la base de données ; PostgreSQL utilise normalement une barre oblique inverse et SQLite n’a pas de caractère d’échappement par défaut.

Négation et volume de recherche

name NOT LIKE '%Lamp%' renvoie les cinq autres produits. Un texte manquant ne satisfait ni LIKE ni NOT LIKE. Parmi les employés, trois numéros correspondent à '312-%', deux numéros enregistrés n’y correspondent pas et les trois numéros NULL n’apparaissent dans aucun des deux résultats.

Un % placé en début de motif ne fournit à un index ordinaire aucun début de texte fixe sur lequel restreindre la recherche : une grande partie de la table peut donc être parcourue. Un début fixe comme 'Desk%' peut aider un index adapté. Pour les dates, utilise des plages de dates : LIKE fonctionne sur ces dates textuelles, mais PostgreSQL exige une conversion avant d’appliquer LIKE à une véritable colonne DATE.

NULL marque une valeur manquante : une valeur peut être inconnue, non enregistrée ou sans objet. Il diffère d’un zéro connu ou d’un texte connu sans caractères.

Comprendre ce que signifie une valeur manquante

Lamp Shade a stock = 0. Sa quantité enregistrée est nulle : il est donc en rupture de stock. Bookshelf a un stock NULL : la quantité n’a pas été enregistrée. La base de données ne peut pas te dire s’il y a zéro unité ou un autre nombre.

Cette distinction change la question à laquelle tu peux répondre :

Une cellule qui paraît vide dans un outil de requête ne suffit pas à distinguer ces états. Certains outils affichent NULL sous forme de cellule vide ; d’autres affichent NULL. Teste directement la valeur stockée.

Utiliser les tests de valeurs manquantes

SELECT first_name
FROM employees
WHERE phone IS NULL;

Ben, Emma et Hugo n’ont pas de numéro de téléphone enregistré. IS NULL donne vrai pour leurs valeurs manquantes. Pour trouver les cinq employés qui ont un numéro enregistré, utilise phone IS NOT NULL : Ana, Chloe, David, Farid et Grace.

N’écris pas phone = NULL pour trouver les numéros manquants. Une comparaison ordinaire impliquant NULL donne inconnu, même lorsque les deux côtés sont NULL. WHERE ne conserve que les lignes pour lesquelles la condition est vraie : = NULL n’en renvoie donc aucune. <> NULL pose le même problème. IS NULL teste la présence du marqueur de valeur manquante et donne une réponse déterminée, vraie ou fausse, pour ces valeurs d’une seule colonne.

La forme NOT phone IS NULL trouve aussi les numéros présents dans SQLite et PostgreSQL, mais phone IS NOT NULL rend le test voulu plus facile à lire.

Distinguer trois formes de texte

SQLite, PostgreSQL, MySQL et SQL Server distinguent la chaîne vide de NULL. phone = '' trouverait les chaînes vides, pas les numéros manquants de Ben, Emma ou Hugo. Si une colonne peut contenir les deux, utilise phone IS NULL OR phone = '' pour trouver l’un ou l’autre état. Oracle traite une valeur textuelle vide comme NULL : cette distinction change donc lorsque tu passes d’une base de données à une autre.

Tenir compte de la formulation et du schéma

« Manquant », « non enregistré » et « non attribué » indiquent IS NULL. department IS NULL trouve Grace. Son service manquant ne signifie pas que le texte du service est le mot 'NULL', et ne permet pas non plus de déterminer son service.

La définition de la table peut déclarer une colonne NOT NULL, ce qui signifie qu’une ligne stockée ne peut pas contenir NULL dans cette colonne. Une requête IS NULL sur une telle colonne ne renvoie aucune ligne. Vérifie cette règle lorsque tu examines un schéma : les colonnes qui autorisent les données manquantes demandent une attention particulière lorsque tu construis des exclusions ou combines des conditions.

Une condition en SQL peut être vraie, fausse ou inconnue. Les valeurs manquantes rendent ce troisième état nécessaire : sans quantité enregistrée, une base de données ne peut pas établir si cette quantité dépasse un seuil.

Une condition et son contraire

Pour Bookshelf, stock > 10 est inconnu, car le stock est NULL. Il en va de même pour stock <= 10. WHERE ne conserve que les lignes dont la condition est vraie et exclut celles dont elle est fausse ou inconnue.

Dans la table des produits, stock > 10 renvoie quatre lignes et stock <= 10 en renvoie trois. Ensemble, elles couvrent sept des huit produits. Bookshelf est absent des deux résultats. Appliquer NOT ne le rétablit pas : la négation d’inconnu est inconnue, donc NOT (stock > 10) ne sélectionne toujours que les trois quantités connues qui valent au plus 10.

Le cas diffère pour une valeur qui ne satisfait pas une condition. Le zéro connu de Lamp Shade rend stock > 10 faux, donc NOT le rend vrai. Une quantité manquante ne fournit aucune comparaison déterminée de ce type à inverser.

Combiner inconnu avec un autre test

Bookshelf coûte 120,00. Dans stock > 10 OR price > 100, la condition sur le prix est vraie. OR n’exige qu’une partie vraie : la ligne est donc conservée même si la comparaison du stock est inconnue. Dans stock > 10 AND price > 100, la condition sur le stock reste indéterminée : le résultat est donc inconnu et la ligne est exclue.

Inclure volontairement les valeurs manquantes

SELECT first_name
FROM employees
WHERE department <> 'Sales'
   OR department IS NULL;

Cette requête renvoie Ben, David, Farid, Hugo et Grace. La comparaison seule en renverrait quatre et exclurait Grace. La branche IS NULL inclut explicitement le personnel sans service attribué. L’inclusion ou non de ces personnes dans « hors de Sales » dépend de la réponse attendue ; la requête doit exprimer ce choix.

Une valeur NULL dans une liste NOT IN peut bloquer tout le résultat. department NOT IN ('Sales', NULL) signifie que le service doit différer de Sales et différer de NULL. Cette dernière comparaison est inconnue pour chaque ligne : la condition complète n’est donc jamais vraie. IN conserve néanmoins les correspondances réelles : department IN ('Sales', NULL) sélectionne les trois employés de Sales, mais ne trouve pas Grace.

Une valeur testée manquante produit aussi inconnu pour LIKE et pour une plage BETWEEN ordinaire. IS NULL et IS NOT NULL donnent des réponses déterminées pour ces colonnes scalaires. Vérifie séparément les valeurs manquantes avec ces tests lorsqu’un nombre de lignes te surprend.

Savoir quand les NULL sont regroupés

NULL = NULL reste inconnu ; on ne sait pas si deux numéros de téléphone manquants sont identiques. DISTINCT traite toutefois les valeurs manquantes répétées comme des doublons et ORDER BY les place ensemble. Pour une comparaison qui traite volontairement deux NULL comme égaux, SQLite et PostgreSQL proposent aussi IS NOT DISTINCT FROM.

ORDER BY définit l’ordre des lignes du résultat. Sans lui, SQL ne garantit pas quelle ligne apparaît en premier, même lorsqu’une petite table semble toujours renvoyer le même ordre.

Choisir le sens

ASC est le sens par défaut. ORDER BY salary et ORDER BY salary ASC demandent le même sens. « Le salaire le plus élevé d’abord » appelle ORDER BY salary DESC.

SELECT first_name, salary
FROM employees
ORDER BY salary DESC;

Lis le résultat du plus élevé au plus bas : Farid 83 000, Ben 71 000, Emma 65 000, David 60 000, Hugo 58 000, Ana 52 000, Chloe 48 000 et Grace 45 000. La base de données réordonne les lignes du résultat ; cette requête ne modifie pas la table stockée.

Filtrer avant de trier

SELECT name, price
FROM products
WHERE category = 'Lighting'
ORDER BY price;

Seules les trois lignes de Lighting entrent dans ce résultat. Leurs prix croissants donnent Lamp Shade 15,50, Desk Lamp 24,99, puis Floor Lamp 89,00. ORDER BY suit WHERE dans l’instruction. Inverser ces clauses provoque une erreur de syntaxe.

La colonne de tri n’a pas besoin d’être affichée. SELECT first_name FROM employees ORDER BY salary DESC; donne le même ordre des noms sans afficher les salaires. PostgreSQL limite cette possibilité en présence de DISTINCT : une requête DISTINCT doit sélectionner ses colonnes de tri.

Lire le type de données stocké

Les colonnes numériques sont triées selon la valeur des nombres. Les colonnes textuelles sont triées caractère par caractère selon leur collation. Les valeurs textuelles '10', '9' et '100' se classent dans l’ordre '10', '100', '9' selon l’ordre ordinaire des caractères. Ce n’est pas un classement numérique correct : vérifie donc le type de la colonne lorsque des montants semblent mal ordonnés.

Les valeurs de hire_date dans l’exemple sont des dates textuelles complètes de largeur fixe, avec l’année en premier. ORDER BY hire_date commence par Farid le 2017-09-12 et se termine par Grace le 2024-02-19. DESC inverse cet ordre pour placer les dernières personnes embauchées en premier. Les dates textuelles commençant par le mois, comme MM/DD/YYYY, sont comparées par mois avant l’année et ne permettent pas d’obtenir un ordre chronologique fiable sur plusieurs années.

L’ordre du texte dépend de la collation

La collation binaire par défaut de SQLite place les lettres ASCII majuscules avant les minuscules. Selon cette règle, 'Zebra' précède 'apple' et 'é' vient après 'z'. De nombreuses bases PostgreSQL utilisent des collations qui tiennent compte de la langue et produisent un autre ordre. Une casse cohérente aide, mais les règles de comparaison de la base déterminent toujours l’ordre des caractères accentués et des autres caractères.

Utilise les noms de colonnes pour préciser clairement le tri. ORDER BY 2 DESC désigne le deuxième élément de la liste SELECT : déplacer des colonnes peut donc modifier le tri sans avertissement. ORDER BY 'salary' désigne une constante textuelle, pas la colonne des salaires : SQLite n’en tire aucun ordre utile et PostgreSQL le refuse. Écris ORDER BY salary.

Une deuxième colonne de tri ne compte que lorsque des lignes sont à égalité sur la première. Pense à une liste de personnel triée : regroupe d’abord par ville, puis classe les noms dans chaque ville.

Suivre les colonnes de tri de gauche à droite

SELECT last_name, city
FROM employees
ORDER BY city, last_name;

Le résultat commence par Kim et Okafor à Boston. Viennent ensuite Haddad, Lopez, Nguyen et O'Neill à Chicago. Brown et Carter à Denver sont en dernier. last_name ne concurrence pas city ; il ne détermine l’ordre qu’au sein d’une même ville.

Inverser les colonnes change l’ordre principal. ORDER BY last_name, city trie principalement par nom de famille et ne consulte la ville qu’en cas de noms identiques. Utilise une seule clause ORDER BY avec des virgules entre ses colonnes de tri. Une deuxième clause ORDER BY est invalide.

Donner son sens à chaque colonne

ORDER BY department, salary DESC signifie que les services sont triés par ordre croissant, puis les salaires par ordre décroissant dans chaque service. DESC ne s’applique qu’au salaire. Pour trier les deux par ordre décroissant, écris department DESC, salary DESC.

Avec l’ordre par défaut des NULL dans SQLite, la première forme place d’abord le service manquant de Grace. IT suit avec Farid puis Ben ; Marketing contient David puis Hugo ; Sales contient Emma, Ana, puis Chloe. Tu lis une hiérarchie de comparaisons : il ne s’agit pas de trier d’abord toutes les lignes par salaire puis d’ignorer cet ordre.

Départager les ex aequo avec une valeur unique

Les lignes égales sur toutes les colonnes de tri peuvent apparaître dans n’importe quel ordre. ORDER BY city ne détermine pas quel employé de Chicago vient en premier. Un ordre de tri total ajoute une dernière colonne qui identifie chaque ligne de manière unique :

SELECT first_name, city
FROM employees
ORDER BY city, employee_id;

Les identifiants départagent tous les employés d’une même ville. Pour des données inchangées, cela permet à un LIMIT ou à une page de sélectionner une partie reproductible de la liste ordonnée. Un critère de départage unique fixe les lignes qui apparaissent à la limite ; il n’ajoute pas les autres lignes ex aequo.

Placer volontairement les valeurs manquantes

Les valeurs par défaut diffèrent selon les bases de données :

La requête sur les services place donc Grace en dernier dans PostgreSQL avec son réglage par défaut, même si elle la place en premier dans SQLite. Cette différence est indépendante du sens de tri du salaire.

SELECT first_name, department, salary
FROM employees
ORDER BY department NULLS LAST, salary DESC;

SQLite 3.30 ou ultérieur, PostgreSQL et Oracle prennent en charge NULLS FIRST et NULLS LAST. Ici, ils placent Grace après tous les services enregistrés tout en conservant l’ordre des salaires dans chaque service. MySQL et SQL Server n’acceptent pas ces clauses.

Traduis la hiérarchie demandée dans l’ordre où elle est énoncée : « par service, avec le salaire le plus élevé d’abord dans chaque service » donne department, salary DESC. « Par ordre alphabétique du nom, puis du prénom » donne last_name, first_name. Ajoute un identifiant en dernier lorsque tu as besoin d’un ordre reproductible entre des personnes ayant les mêmes nom et prénom.

LIMIT conserve au plus un nombre choisi de lignes de résultat. Il ne détermine pas quelles lignes méritent de figurer en premier. Utilise ORDER BY pour donner un sens à une courte liste, comme les mieux payés, les plus récents ou les moins chers.

Trier, puis limiter

SELECT first_name, salary
FROM employees
ORDER BY salary DESC
LIMIT 3;

Les salaires triés commencent par Farid 83 000, Ben 71 000 et Emma 65 000 : ces trois lignes sont donc conservées. Sans ORDER BY, LIMIT 3 renvoie trois lignes quelconques, sans garantir qu’il s’agit des personnes les mieux payées.

WHERE agit avant la limite. WHERE city = 'Boston' ORDER BY salary DESC LIMIT 5 ne renvoie que David et Grace, car seuls deux employés satisfont la condition. LIMIT fixe un maximum : il ne demande pas d’inventer des lignes supplémentaires. LIMIT 0 n’en renvoie aucune.

Sauter des lignes pour une page ultérieure

OFFSET saute des lignes avant que LIMIT ne compte les lignes à renvoyer. ORDER BY salary DESC LIMIT 3 OFFSET 3 saute Farid, Ben et Emma, puis renvoie David, Hugo et Ana : les lignes de rangs quatre à six.

Pour la page k avec n lignes par page, saute (k − 1) × n lignes. La page trois avec trois lignes par page utilise LIMIT 3 OFFSET 6. Seuls Chloe et Grace restent. La première page utilise un décalage de zéro, pas de un.

« Deuxième ligne » et « deuxième valeur différente » sont deux demandes distinctes. ORDER BY salary DESC LIMIT 1 OFFSET 1 renvoie ici Ben avec 71 000. Si deux employés partageaient le salaire le plus élevé, cette requête renverrait une autre personne au salaire le plus élevé. Pour trouver le deuxième salaire différent, sélectionne DISTINCT salary avant de trier et de sauter des lignes.

Départager à la limite

ORDER BY city LIMIT 3 inclut les deux employés de Boston et un employé de Chicago, sans préciser lequel. ORDER BY city, employee_id LIMIT 3 sélectionne David, Grace et Ana. L’identifiant unique départage les lignes à la limite.

Pour conserver toutes les lignes à égalité sur la dernière valeur de tri, PostgreSQL 13 ou ultérieur et Oracle prennent en charge FETCH FIRST 3 ROWS WITH TIES. Avec ORDER BY city, cette clause conserve six lignes : les deux lignes de Boston et les quatre de Chicago. Si ORDER BY inclut aussi un identifiant unique, les lignes ne peuvent pas être à égalité sur la clé de tri complète.

Reconnaître la syntaxe de la base de données

SQL standard utilise OFFSET et FETCH, pas LIMIT. PostgreSQL et Oracle acceptent OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY. SQL Server utilise ORDER BY salary DESC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY ; ORDER BY est obligatoire pour cette forme de pagination.

SQLite et MySQL acceptent aussi LIMIT 6, 3, avec le décalage en premier. Préfère LIMIT 3 OFFSET 6 pour rendre les rôles explicites. La pagination réexécute une requête pour chaque page. Un ordre de tri total maintient la cohérence des pages tant que les données restent inchangées ; des insertions ou des suppressions entre les requêtes peuvent néanmoins faire répéter ou sauter des enregistrements.

Les clauses SQL s’écrivent dans un ordre fixe. Leur ordre logique explique le résultat comme une succession de décisions, même lorsque la base de données utilise un plan d’exécution interne différent.

Écrire l’instruction dans l’ordre des clauses

SELECT DISTINCT city
FROM employees
WHERE department = 'Sales'
ORDER BY city
LIMIT 2 OFFSET 0;

SELECT et FROM indiquent les colonnes demandées et la table source. Les autres clauses sont facultatives, mais lorsqu’elles sont présentes, elles conservent cet ordre : WHERE, ORDER BY, LIMIT, puis OFFSET dans cette forme avec LIMIT. DISTINCT se place immédiatement après SELECT.

Utilise une seule clause WHERE avec plusieurs conditions reliées entre elles. Un deuxième WHERE provoque une erreur de syntaxe. Il en va de même pour ORDER BY : place plusieurs colonnes de tri dans une seule clause, séparées par des virgules. Déplacer WHERE sous ORDER BY ne demande pas un ordre de traitement différent : cela produit du SQL invalide.

Suivre les décisions logiques

Le résultat est Chicago, puis Denver. La ville répétée disparaît avant que la limite ne compte les lignes de résultat. La requête ne prend pas deux employés pour ensuite chercher s’ils vivent dans des villes différentes.

L’optimiseur peut utiliser un plan d’exécution physique différent qui produit le même résultat que cette séquence logique.

Utiliser les colonnes lorsqu’elles sont disponibles

WHERE teste les lignes sources avant que SELECT ne choisisse les colonnes affichées :

SELECT first_name
FROM employees
WHERE salary > 60000;

Cela fonctionne sans afficher le salaire. Les noms retenus sont Ben, Emma et Farid. Le salaire est toujours une colonne de chaque ligne source lorsque le test est effectué.

De même, filtrer avant de limiter est essentiel pour obtenir le premier résultat au sein d’un groupe :

SELECT first_name
FROM employees
WHERE department = 'Sales'
ORDER BY salary DESC
LIMIT 1;

La réponse est Emma. Le personnel de Sales est d’abord retenu ; les salaires de ses membres sont ensuite classés. Prendre d’abord la personne la mieux payée de l’entreprise puis vérifier si cette seule ligne appartient à Sales manquerait la réponse attendue, car Farid appartient à IT.

Rendre la structure visible

Écris une clause par ligne et place les conditions plus longues sur des lignes distinctes en retrait. Pour « les produits de Furniture à moins de 200 dollars, du prix le plus élevé au plus bas », utilise :

SELECT name, price
FROM products
WHERE category = 'Furniture'
  AND price < 200
ORDER BY price DESC;

Office Chair à 149,00 vient avant Bookshelf à 120,00. Les deux conditions partagent un seul WHERE, le seuil numérique n’a pas de symbole monétaire et ORDER BY trie les lignes retenues. Vérifier chaque ligne selon son rôle permet de repérer plus facilement les erreurs de syntaxe comme les mauvaises interprétations.

Avant d’écrire du SQL, repère les décisions distinctes que contient une demande courante. Chaque décision correspond à une clause, et chaque clause peut être vérifiée par rapport à la réponse attendue.

Prendre six décisions

1. Quelle table contient les enregistrements ? Choisis FROM.
2. Quels enregistrements sont retenus ? Construis WHERE.
3. Quels champs répondent à la question ? Choisis SELECT.
4. Les valeurs répétées du résultat sont-elles utiles ? Décide s’il faut DISTINCT.
5. Qu’est-ce qui doit venir en premier ? Construis ORDER BY.
6. Y a-t-il un maximum ou une page ? Ajoute LIMIT et OFFSET.

Pour « au moins », inclus l’égalité. « L’un de » suggère IN, « contient » suggère un motif LIKE avec des signes pourcentage aux deux extrémités, « manquant » suggère IS NULL et « valeurs différentes » suggère DISTINCT. Une demande portant sur les n premiers nécessite à la fois un sens de tri et une limite.

Construire une courte liste de personnel

« Affiche les noms et les dates d’embauche des trois dernières personnes embauchées hors de Sales qui ont un numéro de téléphone enregistré, de la plus récente à la plus ancienne. » Inclus le personnel sans service attribué dans le sens donné ici à « hors de Sales ».

Commence par employees. La règle sur le service des personnes retenues est department <> 'Sales' OR department IS NULL. Regroupe ce choix pour que la règle sur le téléphone s’applique aux deux branches. Affiche les noms et les dates, puis classe les lignes retenues :

SELECT first_name, last_name, hire_date
FROM employees
WHERE (department <> 'Sales' OR department IS NULL)
  AND phone IS NOT NULL
ORDER BY hire_date DESC
LIMIT 3;

Grace Okafor, embauchée le 2024-02-19, est première ; David Kim, embauché le 2020-11-23, deuxième ; et Farid Haddad, embauché le 2017-09-12, troisième. Supprimer la branche IS NULL exclut Grace et ne laisse que deux résultats. Si une demande manque de clarté, décide comment compter les services manquants et indique ton choix avec la réponse.

Combiner catégorie, prix et stock

« Quels produits de Lighting ou de Storage coûtent moins de 20 dollars américains et sont en stock, du moins cher au plus cher ? » Utilise IN pour les deux choix de catégorie et exige une quantité connue positive :

SELECT name, price
FROM products
WHERE category IN ('Lighting', 'Storage')
  AND price < 20
  AND stock > 0
ORDER BY price;

Paper Tray à 9,99 vient avant Desk Organizer à 18,75. Lamp Shade est assez bon marché et appartient à une catégorie choisie, mais son stock est nul : il ne satisfait donc pas le dernier test. Une quantité en stock manquante ne satisferait pas non plus le test, car elle ne permet pas d’établir que le stock est positif.

Vérifier les lignes qui pourraient révéler une erreur

Commence par SELECT * FROM products LIMIT 5; pour explorer le schéma et quelques enregistrements. Ajoute les filtres un à un, en vérifiant les changements du nombre de lignes dans le résultat et en affichant temporairement les colonnes testées lorsque c’est utile.

Teste les bornes exactes, les valeurs manquantes, la casse du texte et les ex aequo à la limite. NOT montre les lignes pour lesquelles une condition était fausse ; il ne révèle pas celles pour lesquelles elle était inconnue. Exécute séparément des tests IS NULL. Vérifie que le résultat contient les colonnes demandées et que ORDER BY départage les ex aequo qui influent sur la réponse.

Lorsque tu transfères la requête vers une autre base de données, vérifie la syntaxe de limitation des lignes, les règles de casse de l’égalité et de LIKE, la délimitation des noms, le traitement des dates et la place des NULL. Les exemples utilisent LIMIT dans SQLite et PostgreSQL ; la forme de limitation des lignes de SQL standard utilise OFFSET avec FETCH FIRST.