SQLite SELECT : interroger lignes, colonnes et expressions

La commande SELECT pour lire les lignes d'une table

Toute requête SQLite commence par SELECT. La logique est simple : donne-moi ces colonnes, dans cette table, pour les lignes qui remplissent ces conditions. Pour aujourd'hui, on se concentre sur les deux premiers éléments — les colonnes et la table. Le filtrage, ce sera pour le prochain doc.

Voici la requête SQLite la plus basique qui soit :

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL,
    stock INTEGER
);

INSERT INTO products (name, price, stock) VALUES
    ('Cahier', 4.50, 120),
    ('Stylo', 1.20, 500),
    ('Sac à dos', 39.99, 25),
    ('Gomme', 0.80, 300);

SELECT * FROM products;

SELECT * veut dire « toutes les colonnes ». FROM products indique la table. On obtient une ligne par enregistrement, avec les quatre colonnes. Le point-virgule termine l'instruction.

Voilà la structure générale : SELECT <colonnes> FROM <table>;.

Sélectionner des colonnes spécifiques en SQLite

L'étoile * est pratique quand on explore une base. Mais dans du vrai code, on préfère presque toujours nommer explicitement les colonnes qui nous intéressent :

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL,
    stock INTEGER
);

INSERT INTO products (name, price, stock) VALUES
    ('Cahier', 4.50, 120),
    ('Stylo', 1.20, 500),
    ('Sac à dos', 39.99, 25);

SELECT name, price FROM products;

Vous récupérez deux colonnes, dans l'ordre demandé. C'est l'ordre de la liste SELECT qui détermine l'ordre dans le résultat — il n'a aucune raison de coller à l'ordre des colonnes dans la table.

Pourquoi privilégier cette approche plutôt qu'un SELECT * ? Deux raisons. D'abord, moins de données transitent (ou sont lues sur le disque), ce qui devient vite critique sur des tables larges. Ensuite, votre requête reste stable si quelqu'un ajoute une colonne à la table le mois prochain. Avec SELECT *, le résultat s'élargit en silence, et ça peut casser un code applicatif qui déballe les lignes par position.

SELECT ne se contente pas de lire : il calcule aussi

Les éléments de la liste SELECT ne sont pas forcément de simples noms de colonnes. Ce peut être n'importe quelle expression sqlite : un calcul arithmétique, un appel de fonction, une concaténation de chaînes, une constante. SQLite évalue l'expression pour chaque ligne.

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL,
    stock INTEGER
);

INSERT INTO products (name, price, stock) VALUES
    ('Cahier', 4.50, 120),
    ('Stylo', 1.20, 500),
    ('Sac à dos', 39.99, 25);

SELECT name, price, stock, price * stock FROM products;

La quatrième colonne n'existe pas dans la table — SQLite l'a calculée ligne par ligne. Vous pouvez faire pareil avec des fonctions de chaîne, des dates, des expressions conditionnelles, vraiment tout ce que vous voulez. La liste du SELECT sert à façonner les données, pas seulement à les récupérer.

On peut même faire un SELECT sans clause FROM, en utilisant SQLite comme une simple calculatrice :

SELECT 2 + 2, upper('bonjour'), length('SQLite');

Une seule ligne, trois colonnes. Pratique pour tester ce que fait une expression avant de la glisser dans une vraie requête.

Renommer les colonnes avec AS

Quand vous calculez une colonne, SQLite lui attribue un nom par défaut — souvent l'expression elle-même, du genre price * stock. C'est moche et instable. Donnez-lui un vrai nom avec AS :

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL,
    stock INTEGER
);

INSERT INTO products (name, price, stock) VALUES
    ('Cahier', 4.50, 120),
    ('Sac à dos', 39.99, 25);

SELECT
    name AS product,
    price * stock AS inventory_value
FROM products;

L'alias devient le nom de la colonne dans le jeu de résultats. C'est utile pour la lisibilité quand on lit la sortie, et ça compte vraiment pour le code applicatif qui récupère les valeurs par nom de colonne (row["inventory_value"] plutôt que row[1]).

Le mot-clé AS est facultatif — price * stock inventory_value fonctionne pareil — mais autant l'écrire explicitement. L'intention est plus claire, et ça évite les confusions avec une virgule oubliée qui pourrait passer pour un alias.

Donner aussi un alias à la table

Vous pouvez également attribuer un alias court à la table elle-même. Ça n'a pas grand intérêt avec une seule table, mais l'habitude paie dès que vous commencez à faire des jointures :

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES ('Cahier', 4.50);

SELECT p.name, p.price FROM products AS p;

p devient un raccourci pour products. La notation pointée p.name indique clairement de quelle table provient une colonne. Avec une seule table, c'est un détail superflu ; mais dès qu'on jongle avec trois tables jointes, c'est ce qui sauve la lisibilité de la requête.

Littéraux et constantes dans le résultat

Rien ne vous empêche de mélanger de vraies colonnes avec des valeurs constantes. Pratique pour étiqueter des lignes ou injecter une valeur par défaut :

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES
    ('Cahier', 4.50),
    ('Stylo', 1.20);

SELECT
    name,
    price,
    'USD' AS currency,
    1 AS active
FROM products;

Chaque ligne renvoie le même 'USD' et le même 1. Ce pattern revient souvent quand on combine plusieurs requêtes avec UNION et qu'il faut une colonne « marqueur » pour distinguer la provenance des résultats.

Petit aparté sur NULL

Certaines colonnes restent vides : soit aucune valeur n'a été insérée, soit la colonne n'a pas de valeur par défaut. SQLite représente cette absence de valeur par NULL. Dans les résultats d'un SELECT, NULL apparaît sous forme de cellule vide ou du mot NULL lui-même, selon l'outil que vous utilisez.

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES
    ('Cahier', 4.50),
    ('Article mystère', NULL);

SELECT name, price, price * 2 AS doubled FROM products;

Regardez la deuxième ligne. price vaut NULL, et price * 2 vaut aussi NULL — toute opération arithmétique impliquant NULL renvoie NULL. C'est l'une des sources de confusion les plus fréquentes en SQL, et une page entière y est consacrée plus loin. Pour l'instant, retiens simplement que NULL se propage à travers les expressions.

Ce qu'il faut retenir

• SELECT <colonnes> FROM <table>; est la forme de toute requête SQLite.
• En vrai code, liste les colonnes explicitement ; garde SELECT * pour l'exploration.
• La liste du SELECT accepte n'importe quelle expression, pas uniquement des noms de colonnes.
• Utilisez AS pour donner un nom propre aux colonnes calculées et aux tables aliasées.
• NULL se propage dans les calculs arithmétiques — pensez-y quand un résultat te paraît bizarre.

La suite : filtrer avec WHERE

Pour le moment, chaque requête renvoie toutes les lignes de la table. La clause WHERE permet de restreindre ça — sélectionner des lignes par prix, par nom, par date, ou via toute expression qui s'évalue à vrai ou faux. C'est l'objet du prochain document.