Description

where and having together ?

# **WHERE et HAVING ensemble : le duo gagnant pour des requêtes SQL puissantes**

*Par *[Votre Nom]* – Blog SQL & Data*

—

## 🎯 Pourquoi parler de `WHERE` + `HAVING` ?

Lorsque l’on débute en SQL, on apprend vite que les filtres sont indispensables : on ne veut pas simplement récupérer *toutes* les lignes d’une table, on veut les **celles qui nous intéressent**.
Deux clauses permettent de le faire, mais elles interviennent à des moments différents du processus de traitement d’une requête :

| Clause | Quand intervient‑elle ? | Sur quoi agit‑elle ? |
|——–|————————–|———————-|
| **`WHERE`** | **Avant** le `GROUP BY` | Sur chaque ligne individuelle |
| **`HAVING`** | **Après** le `GROUP BY` | Sur les **groupes** de lignes (agrégats) |

Les combiner, c’est exploiter le meilleur des deux mondes : filtrer d’abord les lignes brutes, puis affiner le résultat au niveau des agrégats.

—

## 📚 1. Rappel express : `WHERE` vs `HAVING`

### `WHERE`
– **But** : éliminer les lignes qui ne respectent pas une condition.
– **Exemple** : « Ne garder que les ventes de l’année 2023 ».
– **Ordre d’exécution** : première étape de la requête, avant toute agrégation.

### `HAVING`
– **But** : éliminer les **groupes** qui ne respectent pas une condition d’agrégation.
– **Exemple** : « Conserver uniquement les catégories dont le chiffre d’affaires moyen dépasse 10 000 € ».
– **Ordre d’exécution** : appliquée **après** le `GROUP BY`.

—

## 🔗 2. Comment les combiner ? Le flux d’exécution

1. **`FROM`** – Lecture de la table source.
2. **`WHERE`** – Filtrage ligne par ligne.
3. **`GROUP BY`** – Regroupement des lignes filtrées.
4. **`HAVING`** – Filtrage des groupes obtenus.
5. **`SELECT`**, `ORDER BY`, … – Présentation du résultat.

> **Astuce** : si vous avez une condition qui ne dépend pas d’un agrégat, placez‑la toujours dans le `WHERE`. Cela réduit le nombre de lignes à regrouper, ce qui améliore les performances.

—

## 🛠️ 3. Exemple concret

“`sql
SELECT category_id,
AVG(list_price) AS avg_price
FROM product
WHERE model_year = 2016 — 1️⃣ Filtrage ligne par ligne
GROUP BY category_id — 2️⃣ Regroupement
HAVING AVG(list_price) > 1000; — 3️⃣ Filtrage des groupes
“`

– **`WHERE`** ne garde que les produits de l’année 2016.
– **`GROUP BY`** crée un groupe par `category_id`.
– **`HAVING`** ne retient que les catégories dont le prix moyen dépasse 1 000 $.

—

## 📈 4. Scénarios d’utilisation fréquents

### a) Filtrer par rôle avant de calculer un salaire moyen

“`sql
SELECT Department,
AVG(Salary) AS avg_salary
FROM Employees
WHERE Title = ‘Manager’ — On ne s’intéresse qu’aux managers
GROUP BY Department
HAVING AVG(Salary) > 50000; — Et seulement les départements > 50 k$
“`

### b) Analyser les ventes en excluant les petites quantités

“`sql
SELECT Day,
SUM(Quantity) AS total_qty
FROM Sales
WHERE Quantity 1 — Ignorer les ventes d’une unité
GROUP BY Day
HAVING SUM(Quantity) > 3; — Conserver les jours où le total > 3
“`

### c) Combinaison avancée : date, catégorie et seuil d’agrégation

“`sql
SELECT YEAR(order_date) AS yr,
category_id,
COUNT(*) AS nb_orders,
SUM(total_amount) AS revenue
FROM Orders
WHERE order_status = ‘shipped’ — 1️⃣ Seulement les commandes expédiées
AND order_date >= ‘2023-01-01’ — 2️⃣ Depuis le 1er janvier 2023
GROUP BY YEAR(order_date), category_id
HAVING SUM(total_amount) > 50000 — 3️⃣ Revenus > 50 k€ par catégorie/année
AND COUNT(*) >= 10; — Au moins 10 commandes
“`

—

## 🚀 5. Bonnes pratiques & pièges à éviter

| Pratique recommandée | Pourquoi |
|———————-|———-|
| **Mettre les filtres simples dans `WHERE`** | Moins de lignes à regrouper = requête plus rapide |
| **Utiliser `HAVING` uniquement pour les agrégats** | Un `HAVING` mal placé peut masquer un problème de logique |
| **Éviter les fonctions coûteuses dans `WHERE`** (ex. `LIKE ‘%…%’`) | Elles empêchent l’utilisation d’index |
| **Tester chaque clause séparément** | Vous pouvez vérifier rapidement où le problème se situe |
| **Profiter des alias** (`AVG(list_price) AS avg_price`) | Rendre le `SELECT` plus lisible, surtout quand vous réutilisez l’agrégat dans le `HAVING` |

> **Note de performance** : Sur de très gros volumes, le placement d’un filtre `WHERE` peut réduire le temps de `GROUP BY` de plusieurs ordres de grandeur. Pensez toujours à analyser le plan d’exécution (`EXPLAIN`).

—

## 🧩 6. Quand `HAVING` peut remplacer `WHERE` (et vice‑versa)

Il arrive parfois que la même condition puisse être exprimée dans les deux clauses :

“`sql
— Variante 1 – avec WHERE
SELECT *
FROM sales
WHERE quantity > 10;

— Variante 2 – avec HAVING (sans GROUP BY)
SELECT *
FROM sales
HAVING quantity > 10;
“`

**En pratique** :
– **Préférez `WHERE`** dès que vous n’avez pas besoin d’un agrégat.
– **Réservez `HAVING`** aux filtres qui portent sur des fonctions d’agrégation (`SUM`, `AVG`, `COUNT`, …) ou lorsque vous avez déjà un `GROUP BY`.

—

## 📚 7. Ressources complémentaires

– **StackOverflow** – *Is it possible to have a WHERE clause after a HAVING clause?*

– **Microsoft Docs** – *Use HAVING and WHERE clauses in the same query*

– **LearnSQL** – *SQL HAVING vs WHERE*

– **Sling Academy** – *Using WHERE, GROUP BY, HAVING together (MySQL 8)*

—

## 🎉 Conclusion

Combiner `WHERE` et `HAVING` n’est pas une simple curiosité syntaxique : c’est une stratégie indispensable pour **affiner vos analyses**, **optimiser les performances** et **produire des rapports fiables**. En maîtrisant l’ordre d’exécution et en appliquant les bonnes pratiques présentées ici, vous serez capable de concevoir des requêtes SQL à la fois **précises** et **efficaces**, quel que soit le volume de vos données.

> **À vous de jouer !** Prenez un de vos jeux de données, testez les deux filtres séparément, puis ensemble, et observez la différence de résultat et de temps d’exécution. Vous verrez rapidement l’impact du bon placement du `WHERE` et du `HAVING`.

Bon codage, et que vos agrégats restent toujours pertinents ! 🚀

—

*Vous avez aimé cet article ? Partagez-le, commentez vos expériences avec `WHERE`/`HAVING`, ou posez vos questions !*