SQLite GROUP BY et HAVING : filtrer les agrégats

GROUP BY regroupe les lignes par paquets

Les fonctions d'agrégation comme COUNT, SUM et AVG condensent plusieurs lignes en une seule valeur. Avec GROUP BY, vous faites ce calcul par catégorie : un total par client, par mois, par statut. Chaque valeur unique (ou combinaison de valeurs) devient une ligne dans le résultat.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada',   50.00),
    ('Ada',   30.00),
    ('Boris', 80.00),
    ('Boris', 20.00),
    ('Boris', 15.00),
    ('Cleo', 200.00);

SELECT customer, COUNT(*) AS order_count, SUM(amount) AS total
FROM orders
GROUP BY customer;

Trois clients, trois lignes en sortie. Les six lignes d'origine ont disparu : elles ont été regroupées par client, avec COUNT(*) et SUM(amount) calculés à l'intérieur de chaque groupe.

L'idée à retenir : GROUP BY customer revient à dire « considère toutes les lignes ayant le même client comme un seul groupe ». Les fonctions d'agrégation s'appliquent ensuite à chaque groupe indépendamment.

Ce que l'on peut mettre dans la clause SELECT

C'est là que beaucoup se cassent les dents. Avec GROUP BY, chaque colonne du SELECT doit soit figurer dans le GROUP BY, soit être encapsulée dans une fonction d'agrégation. Sinon, la valeur devient ambiguë : laquelle des lignes du groupe SQLite est-il censé renvoyer ?

CREATE TABLE sales (
    region TEXT,
    rep TEXT,
    amount REAL
);

INSERT INTO sales VALUES
    ('North', 'Ada', 100),
    ('North', 'Boris', 200),
    ('South', 'Cleo', 150);

-- Ceci fonctionne : region est groupée, amount est agrégée.
SELECT region, SUM(amount) AS total
FROM sales
GROUP BY region;

Si vous écriviez SELECT region, rep, SUM(amount) avec GROUP BY region, SQLite l'exécuterait sans broncher (il est plus permissif que d'autres SGBD qui rejettent ce genre de requête), mais la valeur de rep serait choisie au hasard dans le groupe. Vous obtiendriez un nom de commercial par région, sans aucune garantie sur lequel. Évitez de compter là-dessus : regroupez sur toutes les colonnes non agrégées que vous affichez.

HAVING : filtrer les groupes après agrégation en SQL

WHERE filtre les lignes avant le regroupement. HAVING filtre les groupes une fois le regroupement effectué. Voilà toute la différence entre WHERE et HAVING, et c'est précisément pour ça qu'on ne peut pas mettre COUNT(*) > 1 dans une clause WHERE : au moment où WHERE s'exécute, le COUNT n'existe pas encore.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada', 50), ('Ada', 30),
    ('Boris', 80), ('Boris', 20), ('Boris', 15),
    ('Cleo', 200);

SELECT customer, COUNT(*) AS order_count
FROM orders
GROUP BY customer
HAVING COUNT(*) > 1;

Cleo n'a passé qu'une seule commande, donc son groupe est écarté. Restent Ada et Boris. La condition s'applique à la valeur agrégée de chaque groupe, et non à chaque ligne prise individuellement.

Bonne nouvelle : dans SQLite, on peut réutiliser directement les alias de colonnes définis dans le SELECT à l'intérieur de la clause HAVING :

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada',   50.00),
    ('Ada',   30.00),
    ('Boris', 80.00),
    ('Boris', 20.00),
    ('Boris', 15.00),
    ('Cleo', 200.00);

SELECT customer, SUM(amount) AS total
FROM orders
GROUP BY customer
HAVING total >= 100;

C'est souvent bien plus lisible que de répéter SUM(amount) dans la clause HAVING.

WHERE et HAVING : les utiliser ensemble

Ces deux clauses ne s'opposent pas, elles se complètent. Le WHERE filtre les lignes avant le regroupement ; le HAVING filtre les groupes une fois constitués. Dans la pratique, la plupart des requêtes SQL utilisent les deux à la fois.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 50, 'paid'),
    ('Ada', 30, 'refunded'),
    ('Boris', 80, 'paid'),
    ('Boris', 20, 'paid'),
    ('Cleo', 200, 'paid'),
    ('Cleo', 50, 'refunded');

SELECT customer, SUM(amount) AS paid_total
FROM orders
WHERE status = 'paid'
GROUP BY customer
HAVING SUM(amount) > 75;

Lisez-le de haut en bas, dans l'ordre d'exécution :

1. WHERE status = 'paid' — on évacue les lignes remboursées dès le départ.
2. GROUP BY customer — on regroupe ce qui reste par client.
3. SUM(amount) est calculée pour chaque groupe.
4. HAVING SUM(amount) > 75 — on ne garde que les groupes qui passent le filtre.

Boris (80 + 20 = 100) et Cleo (200) passent la barre. Côté Ada, sa seule commande payée était de 50, ce qui reste sous le seuil.

Plusieurs conditions et plusieurs colonnes de regroupement

HAVING accepte les mêmes opérateurs booléens que WHERE — AND, OR, NOT — et vous pouvez regrouper sur plusieurs colonnes pour créer des sous-groupes :

CREATE TABLE sales (
    region TEXT,
    quarter TEXT,
    amount REAL
);

INSERT INTO sales VALUES
    ('Nord', 'T1', 100), ('Nord', 'T1', 50),
    ('Nord', 'T2', 300),
    ('Sud', 'T1', 80),
    ('Sud', 'T2', 120), ('Sud', 'T2', 60);

SELECT region, quarter, SUM(amount) AS total, COUNT(*) AS deals
FROM sales
GROUP BY region, quarter
HAVING SUM(amount) > 100 AND COUNT(*) >= 2;

Chaque couple (region, quarter) forme un groupe distinct. La clause HAVING exige à la fois un total supérieur à 100 et au moins deux ventes. Seuls ('Nord', 'T1') et ('Sud', 'T2') passent le filtre.

Cas pratique : repérer les doublons

La requête GROUP BY ... HAVING COUNT(*) > 1 est la méthode classique pour détecter les valeurs en double dans une colonne :

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT
);

INSERT INTO users (email) VALUES
    ('ada@example.com'),
    ('boris@example.com'),
    ('ada@example.com'),
    ('cleo@example.com'),
    ('boris@example.com');

SELECT email, COUNT(*) AS occurrences
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Deux doublons remontent. À partir de là, vous déciderez généralement s'il faut fusionner les comptes, ajouter une contrainte UNIQUE, ou nettoyer les données — mais la requête de détection garde toujours la même forme.

HAVING sans GROUP BY

C'est un cas de figure rare, mais parfaitement valide. En l'absence de GROUP BY, l'ensemble des résultats est considéré comme un seul groupe, et HAVING filtre ce groupe en bloc : soit vous récupérez toutes les valeurs agrégées, soit rien du tout :

CREATE TABLE orders (id INTEGER PRIMARY KEY, amount REAL);
INSERT INTO orders (amount) VALUES (50), (30), (80);

SELECT COUNT(*) AS total_orders, SUM(amount) AS revenue
FROM orders
HAVING SUM(amount) > 100;

La ligne de résultat unique apparaît parce que la somme vaut 160. Si vous changez le seuil en > 200, la requête ne renvoie plus aucune ligne. En pratique, on combine presque toujours HAVING avec GROUP BY — mais c'est bon à savoir : le langage ne l'impose pas.

Récapitulatif express

• GROUP BY regroupe les lignes par clé ; les fonctions d'agrégation s'appliquent à chaque groupe.
• Toute colonne non agrégée présente dans le SELECT doit aussi figurer dans le GROUP BY.
• WHERE filtre les lignes avant le regroupement ; HAVING filtre les groupes après.
• Les agrégats comme COUNT(*) et SUM(...) vont dans HAVING, jamais dans WHERE.
• HAVING accepte des conditions composées et peut s'appuyer sur les alias définis dans le SELECT.

La suite : les clés étrangères

Agréger les données d'une seule table, c'est déjà pratique, mais la plupart des schémas réels répartissent l'information sur plusieurs tables — les commandes d'un côté, les clients d'un autre, les produits ailleurs encore. Les clés étrangères servent justement à relier ces tables entre elles pour garantir la cohérence des relations. C'est ce qu'on aborde au prochain chapitre.