Dans le domaine du reporting et de l'analyse de données, la capacité à manipuler et transformer les données est primordiale. L'instruction `CASE WHEN` en SQL offre une puissance inégalée pour implémenter une logique conditionnelle complexe au sein de vos requêtes de reporting. Elle permet de créer des colonnes dérivées, de segmenter les données et d'appliquer des règles métier spécifiques pour une analyse de données approfondie. L'imbrication de ces instructions offre une flexibilité encore plus grande, permettant de gérer des scénarios de reporting très complexes.
Nous examinerons la syntaxe de `CASE WHEN` et comment l'imbriquer efficacement, les cas d'usage avancés dans le reporting, les techniques d'optimisation pour améliorer la performance des requêtes, les alternatives à `CASE WHEN` et leurs considérations de performance, les bonnes pratiques à suivre pour éviter les pièges courants et garantir la qualité du code SQL, et enfin, des exemples concrets et étoffés illustrant l'application de `CASE WHEN` dans des scénarios réels.
Comprendre la syntaxe et la logique de base de CASE WHEN en SQL
L'expression `CASE WHEN` est une construction fondamentale en SQL qui permet d'évaluer des conditions et de retourner des résultats différents en fonction de ces conditions. Cette fonctionnalité est particulièrement utile pour créer des colonnes calculées, pour segmenter les données en fonction de critères spécifiques et pour implémenter une logique conditionnelle complexe. L'imbrication de ces expressions permet de créer une arborescence de logique conditionnelle, où le résultat d'un `CASE WHEN` influence l'évaluation des suivants. Comprendre la syntaxe et la logique est essentiel pour utiliser cette fonctionnalité efficacement et éviter des erreurs dans vos requêtes de reporting SQL.
Syntaxe fondamentale de CASE WHEN
La syntaxe de base de `CASE WHEN` est la suivante :
CASE WHEN condition1 THEN result1 WHEN condition2 THEN result2 ELSE result_default END Cette syntaxe évalue les conditions de manière séquentielle. Si `condition1` est vraie, `result1` est retourné. Sinon, `condition2` est évaluée, et ainsi de suite. Si aucune condition n'est vraie, `result_default` est retourné. Il existe une variante syntaxique qui permet de comparer une expression à différentes valeurs, améliorant ainsi la lisibilité dans certains cas:
CASE expression WHEN value1 THEN result1 WHEN value2 THEN result2 ELSE result_default END Dans ce cas, la `expression` est comparée successivement à `value1`, `value2` et ainsi de suite. Le `result` correspondant à la première `value` qui correspond à `expression` est retourné. Si aucune `value` ne correspond, `result_default` est retourné. L'utilisation appropriée de cette syntaxe permet d'améliorer la clarté des requêtes SQL et facilite la maintenance du code.
Syntaxe de l'imbrication de CASE WHEN
L'imbrication de `CASE WHEN` consiste à inclure une expression `CASE WHEN` à l'intérieur d'une autre. Cela permet de créer une logique conditionnelle plus complexe, où le résultat d'une condition influence l'évaluation d'autres conditions. La syntaxe est la suivante:
CASE WHEN condition1 THEN CASE WHEN condition2 THEN result2 ELSE result2_default END ELSE result1_default END Dans cet exemple, si `condition1` est vraie, l'expression `CASE WHEN` interne est évaluée. Sinon, `result1_default` est retourné. Il est important de bien indenter le code pour faciliter la lecture et la compréhension de la logique conditionnelle. L'imbrication de `CASE WHEN` est un outil puissant pour implémenter des règles métier complexes dans vos requêtes de reporting.
Gestion de la valeur NULL dans les requêtes SQL
La gestion des valeurs `NULL` est cruciale lors de l'utilisation de `CASE WHEN` dans les requêtes SQL. Une condition impliquant `NULL` sera généralement évaluée comme inconnue, et peut ne pas correspondre à ce qui est attendu. Il faut donc gérer explicitement ces cas pour éviter des résultats incorrects dans vos rapports. L'utilisation de `IS NULL` et `IS NOT NULL` est essentielle pour vérifier si une valeur est `NULL` ou non.
CASE WHEN column_name IS NULL THEN 'Valeur manquante' ELSE column_name END Cet exemple remplace les valeurs `NULL` dans `column_name` par la chaîne 'Valeur manquante'. La gestion correcte des valeurs `NULL` garantit l'intégrité et la fiabilité de vos données de reporting. Il est recommandé de toujours tester vos requêtes avec des données contenant des valeurs `NULL` pour vous assurer que la logique fonctionne correctement.
Cas d'usage avancés pour le reporting avec CASE WHEN imbriqué
L'imbrication de `CASE WHEN` ouvre la voie à une multitude de cas d'usage avancés dans le domaine du reporting. Elle permet de créer des segmentations complexes de clients, d'analyser des performances en fonction de critères spécifiques, de catégoriser dynamiquement des données et de gérer des erreurs avec précision. Comprendre ces cas d'usage est essentiel pour exploiter pleinement la puissance de cette fonctionnalité et créer des rapports pertinents et informatifs.
Segmentation de clients basée sur l'historique d'achat et le comportement en ligne
On peut segmenter des clients selon de multiples critères imbriqués. Par exemple, classifier un client en "Premium" si ses achats des 12 derniers mois dépassent 1000€, qu'il a effectué au moins 5 commandes, qu'il est inscrit à la newsletter et qu'il a visité le site web au moins 10 fois au cours du dernier mois, sinon en "Standard" si ses achats dépassent 500€ et qu'il a effectué au moins 2 commandes, et enfin en "Basique" dans tous les autres cas. Ce type de segmentation aide les équipes marketing à cibler les clients avec des offres personnalisées.
CASE WHEN achats_12mois > 1000 AND nombre_commandes >= 5 AND inscrit_newsletter = 1 AND visites_site_30jours >= 10 THEN 'Premium' WHEN achats_12mois > 500 AND nombre_commandes >= 2 THEN 'Standard' ELSE 'Basique' END AS segment_client Cet exemple illustre la segmentation basée sur plusieurs critères. On peut ensuite étendre cela pour des segmentations encore plus fines en imbriquant d'avantage les `CASE WHEN`. Par exemple, on pourrait ajouter un critère basé sur le taux de satisfaction client (CSAT) pour affiner la segmentation.
Analyse de performance des campagnes marketing avec CASE WHEN
`CASE WHEN` peut être utilisé pour calculer des indicateurs clés de performance (KPI) basés sur différentes conditions. Par exemple, calculer le taux de conversion en fonction du type de campagne et de la source du trafic. Si une campagne est de type "Emailing" et que le trafic provient de "Google Ads", alors on utilise une formule spécifique pour calculer le taux de conversion, prenant en compte le coût par clic (CPC) moyen de la campagne. Sinon, si la campagne est de type "Réseaux Sociaux" et que le trafic provient de "Facebook Ads", on utilise une autre formule, prenant en compte le coût par mille impressions (CPM) de la campagne. Dans tous les autres cas, on utilise une formule par défaut.
CASE WHEN type_campagne = 'Emailing' AND source_trafic = 'Google Ads' THEN (nombre_conversions * 100.0) / nombre_clics_google WHEN type_campagne = 'Réseaux Sociaux' AND source_trafic = 'Facebook Ads' THEN (nombre_conversions * 100.0) / nombre_clics_facebook ELSE (nombre_conversions * 100.0) / nombre_clics_total END AS taux_conversion Cela permet d'adapter le calcul du KPI en fonction du contexte spécifique de chaque campagne et de chaque source de trafic. Par exemple, une campagne d'emailing avec un CPC de 0.50€ pourrait avoir un objectif de taux de conversion plus élevé qu'une campagne sur les réseaux sociaux avec un CPM de 5€.
Catégorisation dynamique de données : niveaux de risque de crédit
Il est possible de créer des catégories personnalisées en fonction de la valeur des données. Prenons l'exemple de la catégorisation de clients en fonction de leur score de crédit : les clients avec un score inférieur à 600 seront classés comme "Haut Risque", ceux entre 600 et 700 comme "Moyen Risque", et ceux au-dessus de 700 comme "Faible Risque". Une banque pourrait utiliser cette catégorisation pour déterminer les taux d'intérêt applicables aux prêts.
CASE WHEN score_credit < 600 THEN 'Haut Risque' WHEN score_credit BETWEEN 600 AND 700 THEN 'Moyen Risque' ELSE 'Faible Risque' END AS categorie_risque Ces catégories sont dynamiques et s'adaptent à la valeur du score de crédit pour chaque client. Par exemple, un client avec un score de 580 sera automatiquement classé comme "Haut Risque".
- Segmentation de la clientèle basée sur des critères complexes
- Analyse de performance des campagnes marketing avec des KPI personnalisés
- Catégorisation de produits en fonction de la marge bénéficiaire
Gestion d'erreurs et de valeurs manquantes dans les données
Il est important de gérer les cas où des données sont manquantes ou erronées. Par exemple, on peut remplacer les valeurs `NULL` par une valeur par défaut, ou afficher un message d'erreur si une valeur invalide est rencontrée. Par exemple, si un champ "âge" est `NULL`, on peut le remplacer par "Âge inconnu".
CASE WHEN valeur IS NULL THEN 'Valeur inconnue' WHEN valeur < 0 THEN 'Erreur : valeur négative' ELSE valeur END Cet exemple remplace les valeurs `NULL` par "Valeur inconnue" et affiche un message d'erreur si la valeur est négative. Sinon, la valeur est retournée. Une gestion rigoureuse des erreurs est essentielle pour garantir la qualité des rapports.
Création de colonnes pivot pour des analyses de ventes mensuelles par région
L'imbrication de `CASE WHEN` permet de créer des colonnes pivot, transformant ainsi des données de format "ligne" vers "colonne". Imaginez que vous avez une table avec des données de ventes par région et par mois. Vous pouvez utiliser `CASE WHEN` pour créer une colonne pour chaque mois et afficher les ventes correspondantes. Cette technique améliore grandement la lisibilité des données pour certains types de rapports, permettant une vue d'ensemble rapide des performances par région et par mois.
SELECT region, SUM(CASE WHEN mois = 'Janvier' THEN ventes ELSE 0 END) AS Janvier, SUM(CASE WHEN mois = 'Février' THEN ventes ELSE 0 END) AS Février, SUM(CASE WHEN mois = 'Mars' THEN ventes ELSE 0 END) AS Mars, SUM(CASE WHEN mois = 'Avril' THEN ventes ELSE 0 END) AS Avril, SUM(CASE WHEN mois = 'Mai' THEN ventes ELSE 0 END) AS Mai, SUM(CASE WHEN mois = 'Juin' THEN ventes ELSE 0 END) AS Juin FROM ventes_par_region GROUP BY region Cet exemple crée une colonne pour chaque mois (Janvier, Février, Mars, Avril, Mai, Juin) et affiche les ventes correspondantes pour chaque région. Cela permet de comparer facilement les performances des différentes régions au cours des différents mois.
Optimisation des requêtes CASE WHEN imbriquées pour une meilleure performance
Bien que puissantes, les requêtes `CASE WHEN` imbriquées peuvent devenir coûteuses en termes de performances si elles ne sont pas optimisées correctement. Plusieurs techniques peuvent être utilisées pour améliorer l'efficacité de ces requêtes et réduire le temps d'exécution. Ces techniques comprennent l'indexation des colonnes utilisées dans les conditions, la simplification de la logique pour éviter des calculs inutiles, l'optimisation de l'ordre des conditions pour filtrer les données plus rapidement, et l'analyse du plan d'exécution pour identifier les goulots d'étranglement et apporter les améliorations nécessaires.
Indexation des colonnes pour accélérer les requêtes SQL
L'indexation des colonnes utilisées dans les conditions `CASE WHEN` est une étape cruciale pour améliorer les performances. Un index permet à la base de données de localiser rapidement les lignes correspondant à une condition spécifique, sans avoir à parcourir toute la table. Il est important de choisir les index appropriés en fonction des conditions les plus fréquemment utilisées. Par exemple, si vous filtrez souvent par la colonne "statut_commande", il est judicieux de créer un index sur cette colonne.
CREATE INDEX idx_statut_commande ON commandes (statut_commande); Cet exemple crée un index sur la colonne "statut_commande" de la table "commandes". L'indexation peut réduire le temps d'exécution des requêtes de 50% à 90% dans certains cas.
Simplification de la logique et réécriture des requêtes complexes
Il est essentiel de simplifier la logique des requêtes `CASE WHEN` imbriquées pour améliorer leur lisibilité et leurs performances. Évitez les conditions redondantes ou inutiles. Décomposez les requêtes complexes en sous-requêtes plus simples et utilisez des variables temporaires pour stocker les résultats intermédiaires. Par exemple, au lieu d'imbriquer plusieurs `CASE WHEN`, vous pouvez créer une vue qui calcule un résultat intermédiaire et l'utiliser dans la requête principale. Une requête SQL bien structurée est plus facile à comprendre et à optimiser.
Ordre des conditions et filtrage des données en amont
L'ordre des conditions dans les expressions `CASE WHEN` peut avoir un impact significatif sur les performances. Placez les conditions les plus fréquentes en premier pour réduire le temps d'exécution. Mettez les conditions qui filtrent le plus de lignes en premier. Par exemple, si 95% des lignes ont une certaine valeur dans une colonne, placez cette condition en premier. Cela permet de réduire le nombre de lignes qui doivent être évaluées par les conditions suivantes.
Utilisation d'alternatives : COALESCE, NULLIF et tables de lookup
Dans certains cas, des alternatives à `CASE WHEN` peuvent être plus performantes. Par exemple, les fonctions `COALESCE` et `NULLIF` peuvent être utilisées pour gérer les valeurs `NULL` de manière plus efficace. Les tables de lookup peuvent également être utilisées pour stocker les correspondances conditionnelles. Il est important d'évaluer les différentes options et de choisir celle qui offre les meilleures performances pour votre cas d'usage spécifique. Discutons des alternatives telles que COALESCE et NULLIF, et quand elles peuvent s'avérer plus performantes.
Analyse du plan d'exécution des requêtes pour identifier les goulots d'étranglement
L'analyse du plan d'exécution de la requête est un outil précieux pour identifier les goulots d'étranglement et optimiser les performances. La plupart des bases de données offrent un outil d'analyse du plan d'exécution qui permet de visualiser les étapes suivies par la base de données pour exécuter la requête. Interprétez le plan d'exécution et apportez les modifications nécessaires à la requête. Par exemple, si le plan d'exécution montre que la base de données effectue un parcours complet de la table (table scan), vous pouvez envisager de créer un index pour accélérer la recherche.
Benchmark : mesurer les performances et quantifier les améliorations
Le benchmark est essentiel pour quantifier les améliorations apportées par l'optimisation. Mesurez les performances de la requête avant et après l'optimisation pour évaluer l'impact des modifications. Utilisez des outils de benchmark pour mesurer le temps d'exécution, l'utilisation du CPU et l'utilisation de la mémoire. Le benchmark permet de valider objectivement les gains de performance et de s'assurer que l'optimisation a bien l'effet escompté. Par exemple, vous pourriez constater une réduction de 30% du temps d'exécution après avoir créé un index. Un benchmark rigoureux vous permet de valider que vos optimisations sont réellement efficaces.
- Indexation des colonnes utilisées dans les conditions `CASE WHEN`
- Simplification de la logique des expressions pour éviter des calculs inutiles
- Analyse du plan d'exécution pour identifier les goulots d'étranglement
- Benchmark des performances avant et après optimisation pour quantifier les gains
Alternatives à CASE WHEN et considérations de performance
Bien que `CASE WHEN` soit très flexible, il existe des alternatives pouvant être plus performantes ou plus lisibles dans certains cas. `COALESCE` et `NULLIF` en sont deux exemples courants. De même, l'utilisation de tables de lookup peut simplifier grandement la logique, au prix d'une maintenance accrue. Le choix de la meilleure approche dépend du contexte spécifique et des exigences de performance.
Fonctions COALESCE et NULLIF : simplifier la gestion des valeurs NULL
La fonction `COALESCE` retourne la première valeur non `NULL` d'une liste d'expressions. Elle peut être utilisée pour remplacer les valeurs `NULL` par une valeur par défaut de manière plus concise qu'avec `CASE WHEN`. Par exemple, `COALESCE(colonne1, 'Valeur par défaut')` retourne la valeur de `colonne1` si elle n'est pas `NULL`, sinon elle retourne 'Valeur par défaut'. COALESCE est souvent plus performant dans les cas simples de remplacement de `NULL` par une valeur par défaut.
La fonction `NULLIF` retourne `NULL` si deux expressions sont égales, sinon elle retourne la première expression. Elle peut être utilisée pour éviter les divisions par zéro ou pour simplifier certaines conditions. Par exemple, `NULLIF(a, b)` retourne `NULL` si `a` est égal à `b`, sinon elle retourne `a`. Dans des conditions simples de remplacement de NULL par une valeur par défaut, COALESCE est souvent plus lisible et performant. Une analyse du plan d'exécution peut vous aider à déterminer quelle approche est la plus performante dans votre cas spécifique.
Tables de lookup : simplifier la logique conditionnelle complexe
Les tables de lookup sont des tables qui stockent les correspondances conditionnelles. Au lieu d'utiliser des expressions `CASE WHEN` complexes, vous pouvez joindre votre table principale à la table de lookup pour obtenir la valeur correspondante. Les tables de lookup sont particulièrement utiles lorsque vous avez un grand nombre de conditions (par exemple, plus de 10 conditions) ou lorsque les conditions sont susceptibles de changer fréquemment. Cette méthode facilite grandement la maintenance du code et peut améliorer la lisibilité des requêtes.
Supposons que vous souhaitiez attribuer des catégories de risque (Faible, Moyen, Elevé) à des clients en fonction de leur score de crédit. Vous pouvez créer une table de lookup qui associe chaque plage de score de crédit à une catégorie de risque. Ensuite, vous pouvez joindre la table de lookup à votre table de clients pour obtenir la catégorie de risque correspondante.
SELECT clients.*, risque.categorie_risque FROM clients JOIN table_lookup_risque risque ON clients.score_credit BETWEEN risque.score_min AND risque.score_max; Cette approche est plus modulaire et facile à mettre à jour que d'utiliser de multiples `CASE WHEN`. Elles sont particulièrement utiles si les règles de classification sont susceptibles de changer fréquemment. L'impact sur la performance est cependant dépendant de la taille de la table de lookup et des index. Pour une table de lookup de moins de 1000 lignes, l'impact sur la performance est généralement négligeable.
< SELECT clients.*, risque.categorie_risque FROM clients JOIN table_lookup_risque risque ON clients.score_credit BETWEEN risque.score_min AND risque.score_max;Fonctions définies par l'utilisateur (UDF) : réutiliser la logique et modulariser le code
Les Fonctions Définies par l'Utilisateur (UDF) permettent d'encapsuler une logique conditionnelle complexe dans une fonction réutilisable. Au lieu d'écrire la même expression `CASE WHEN` plusieurs fois, vous pouvez créer une UDF qui effectue la logique et l'appeler à partir de vos requêtes. Les UDF améliorent la modularité et la maintenabilité du code, en particulier lorsque la même logique doit être appliquée dans plusieurs requêtes. Par exemple, une UDF pourrait être créée pour calculer le taux de TVA en fonction du type de produit et de la région. La fonction pourrait ensuite être appelée dans toutes les requêtes de facturation.
Cependant, l'utilisation d'UDF peut avoir un impact sur les performances, car elles peuvent introduire une surcharge liée au contexte de commutation. Il est important de peser les avantages de la réutilisabilité par rapport à l'impact potentiel sur les performances avant d'utiliser des UDF. Dans certains cas, une UDF peut rendre la requête plus lente de 10% à 20% qu'une longue série de `CASE WHEN`. Un benchmark est essentiel pour évaluer l'impact réel des UDF sur les performances.
- COALESCE : Simplifier la gestion des valeurs NULL
- NULLIF : Éviter les divisions par zéro
- Tables de lookup : Simplifier la logique conditionnelle complexe
Bonnes pratiques et pièges à éviter lors de l'utilisation de CASE WHEN en SQL
Pour utiliser `CASE WHEN` imbriqué de manière efficace et éviter les problèmes, il est important de suivre certaines bonnes pratiques et d'être conscient des pièges courants. Une bonne indentation, des commentaires clairs et une gestion rigoureuse des valeurs `NULL` sont essentiels. Il est aussi important de tester rigoureusement les requêtes pour s'assurer qu'elles renvoient les résultats attendus et de valider que la logique est correcte. Ignorer ces bonnes pratiques peut entraîner des erreurs et des problèmes de performance.
Lisibilité du code SQL : indentation, commentaires et structure claire
La lisibilité du code est primordiale, surtout lorsque vous utilisez des expressions `CASE WHEN` imbriquées. Utilisez une indentation appropriée pour faciliter la lecture de la requête. Ajoutez des commentaires pour expliquer la logique des conditions. Évitez les imbrications excessives pour maintenir la clarté. Par exemple, séparez les expressions `CASE WHEN` complexes en sous-requêtes plus simples pour améliorer la lisibilité. Une requête bien formatée est plus facile à comprendre, à maintenir et à déboguer. Un code clair réduit les risques d'erreurs et facilite la collaboration entre les développeurs.
Gestion rigoureuse des clauses ELSE dans les expressions CASE WHEN
Il est crucial d'inclure une clause `ELSE` dans chaque expression `CASE WHEN` pour gérer les cas où aucune condition n'est remplie. Si vous ne spécifiez pas de clause `ELSE`, la base de données retournera `NULL` par défaut, ce qui peut entraîner des résultats inattendus et des erreurs dans vos rapports. Utilisez `ELSE NULL` si aucune valeur par défaut n'est appropriée, mais assurez-vous que cela correspond à la logique métier. Omettre la clause ELSE est une erreur courante qui peut avoir des conséquences graves sur l'exactitude des données.
Éviter la duplication de code et favoriser la réutilisation
Évitez la duplication de code en réutilisant la même logique conditionnelle dans plusieurs parties de la requête. Créez des vues ou des sous-requêtes pour factoriser le code. Cela améliore la maintenabilité et réduit le risque d'erreurs. Par exemple, si vous utilisez la même expression `CASE WHEN` dans plusieurs requêtes, créez une vue qui effectue le calcul et utilisez la vue dans vos requêtes. Cela permet de centraliser la logique et de faciliter les mises à jour.
Tests unitaires : valider la logique et garantir la fiabilité des requêtes
Écrivez des tests unitaires pour valider la logique de `CASE WHEN`. Testez différents scénarios et utilisez des jeux de données de test. Assurez-vous que la requête renvoie les résultats attendus dans différents scénarios. Les tests unitaires aident à détecter les erreurs et à garantir la fiabilité de vos requêtes. Un test unitaire vérifie si, avec certaines données d'entrées, la `CASE WHEN` renvoie la valeur attendue. Un ensemble complet de tests unitaires est essentiel pour garantir la qualité et l'exactitude des données.
Exemples concrets et étoffés de CASE WHEN pour l'optimisation du reporting
Pour illustrer au mieux l'utilisation de `CASE WHEN` dans des contextes réels et démontrer son efficacité pour l'optimisation du reporting, nous allons explorer plusieurs exemples détaillés. Ces exemples couvriront différents cas d'usage et mettront en évidence les bonnes pratiques d'optimisation, ainsi que les pièges à éviter. Chaque exemple sera accompagné d'une explication claire et concise de la logique et du code SQL.
-- Exemple 1 : Segmentation de clients par pays et âge pour une campagne marketing ciblée SELECT nom, pays, age, CASE WHEN pays = 'France' THEN CASE WHEN age < 30 THEN 'France - Jeune' ELSE 'France - Adulte' END WHEN pays = 'USA' THEN CASE WHEN age < 25 THEN 'USA - Jeune' ELSE 'USA - Adulte' END ELSE 'Autre pays' END AS segment_client FROM clients; Cet exemple segmente les clients en fonction de leur pays et de leur âge, en utilisant `CASE WHEN` imbriqué pour gérer différentes conditions. Cela permet de cibler les campagnes marketing en fonction du profil des clients.
-- Exemple 2 : Calcul de la commission des employés en fonction de leurs ventes et de leur ancienneté SELECT nom, ventes, CASE WHEN ventes > 100000 THEN CASE WHEN anciennete > 5 THEN ventes * 0.05 -- Commission plus élevée pour les employés expérimentés ELSE ventes * 0.03 -- Commission standard END ELSE ventes * 0.01 -- Commission minimale END AS commission FROM employes; Cet exemple calcule la commission des employés en fonction de leurs ventes et de leur ancienneté, en utilisant `CASE WHEN` imbriqué pour appliquer différentes formules. Cela motive les employés à augmenter leurs ventes et à rester longtemps dans l'entreprise.
-- Exemple 3: Catégoriser le niveau d'inventaire d'un produit pour optimiser la gestion des stocks SELECT produit, quantite_en_stock, CASE WHEN quantite_en_stock < 10 THEN 'Critique' -- Risque de rupture de stock WHEN quantite_en_stock BETWEEN 10 AND 50 THEN 'Bas' -- Nécessité de réapprovisionnement WHEN quantite_en_stock BETWEEN 51 AND 100 THEN 'Moyen' -- Niveau d'inventaire acceptable ELSE 'Haut' -- Inventaire suffisant END AS niveau_inventaire FROM inventaire Cet exemple categorise le niveau d'inventaire d'un produit en fonction de la quantité en stock, illustrant comment utiliser `CASE WHEN` pour créer des catégories dynamiques et optimiser la gestion des stocks. Cela permet d'éviter les ruptures de stock et de réduire les coûts de stockage.
-- Exemple 4 : Gérer des erreurs de date et formater les données pour les rapports SELECT date_commande, CASE WHEN date_commande IS NULL THEN 'Date de commande inconnue' -- Gérer les valeurs NULL WHEN date_commande > CURRENT_DATE THEN 'Erreur: Date de commande future' -- Gérer les erreurs de date ELSE CAST(date_commande AS VARCHAR) -- Formater la date pour l'affichage END AS date_commande_formattee FROM commandes; Cet exemple montre comment gérer les valeurs NULL ou erronées dans les dates en utilisant une expression `CASE WHEN` et formater la date si elle est valide. Cela garantit la qualité des données affichées dans les rapports.