Réponse.

En SQL, un filtrage dynamique est souvent requis — par exemple, dans des rapports ou des recherches, lorsque les filtres sont définis par l'utilisateur. Les approches principales sont :

SQL dynamique — la chaîne de requête est construite à la volée avec des conditions uniquement pour les paramètres non vides. C'est flexible, mais nécessite une attention particulière à la protection contre les injections SQL (utiliser des paramètres/échappement).
Filtrage conditionnel par OR — utiliser des constructions (@param IS NULL OR champ = @param), afin d'éviter que les conditions superflues n'affectent le résultat si le paramètre n'est pas défini. Cette méthode est sûre, mais peut parfois entraîner une utilisation sous-optimale des index.

Exemple de modèle pour la recherche de commandes :

SELECT * FROM Orders
WHERE
    (@CustomerID IS NULL OR CustomerID = @CustomerID)
    AND (@Status IS NULL OR Status = @Status)
    AND (@DateFrom IS NULL OR OrderDate >= @DateFrom)
    AND (@DateTo IS NULL OR OrderDate <= @DateTo);

Question piège.

Question : Pourquoi la performance peut-elle parfois se dégrader lors de l'utilisation de l'approche (@param IS NULL OR Column = @param) — même avec un index sur Column ?

Réponse : Ce modèle empêche l'optimiseur d'utiliser l'index efficacement, car une variable est impliquée dans la condition, et la requête se transforme en un scan complet de la table au lieu d'une recherche d'index. Sur de grands volumes de données, cela est critique.

Exemple :

WHERE (@name IS NULL OR name = @name)

Cette condition n'est pas la même que simplement name = @name, ce qui ne permet pas à la SGBD d'utiliser facilement l'index.

Histoire

Dans le service de recherche de la base client, nous avons mis en œuvre des "filtres flexibles" via le modèle (@par IS NULL OR Field = @par), et avec l'augmentation du volume des commandes, la vitesse de recherche est passée de secondes à minutes — les index ont cessé de fonctionner, car l'optimiseur ne pouvait pas déterminer la valeur précise.

Histoire

Dans un projet de e-commerce, le filtrage était réalisé par SQL dynamique sans paramètres, en insérant les valeurs directement. Des injections ont permis aux utilisateurs d'obtenir des listes de tous les clients, car le filtre était vulnérable — les mots de passe ont dû être changés d'urgence.

Histoire

Les rapports BI étaient construits via un modèle paramétré sans tenir compte du fait que les conditions par OR éliminaient les scans indexés. Sur des ensembles de millions, les rapports "se bloquaient" jusqu'à ce que le filtrage soit réécrit avec des conditions obligatoires et une logique distincte pour différentes combinaisons de paramètres.

Comment réaliser efficacement la logique conditionnelle de filtrage des données en SQL lorsque les paramètres de recherche sont définis dynamiquement (par exemple, un filtre web avec n'importe quel ensemble de conditions) ?

Réponse.

Question piège.