Antwoord.

In SQL is dynamische filtering vaak vereist — bijvoorbeeld in rapporten of zoekopdrachten, wanneer filters door de gebruiker worden ingesteld. De belangrijkste benaderingen zijn:

Dynamische SQL — de query-string wordt ter plekke opgebouwd met voorwaarden alleen voor niet-lege parameters. Dit is flexibel, maar vereist aandacht voor bescherming tegen SQL-injecties (gebruik parameters/escapen).
Voorwaardelijke filtering via OR — gebruik constructies (@param IS NULL OF veld = @param), zodat overbodige voorwaarden de resultaten niet beïnvloeden als de parameter niet is ingesteld. Deze methode is veilig, maar kan soms leiden tot suboptimale indexgebruik.

Voorbeeld van een sjabloon voor het zoeken naar bestellingen:

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);

Vragende vraag.

Vraag: Waarom kan de prestaties soms verslechteren bij het gebruik van de aanpak (@param IS NULL OF Column = @param) — zelfs als er een index op Column is?

Antwoord: Dit sjabloon belemmert de optimizer om de index effectief te gebruiken, omdat een variabele in de voorwaarde zit, en de query verandert in een volledige tabelscan in plaats van een indexzoekopdracht. Bij grote datavolumes is dit kritiek.

Voorbeeld:

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

Deze voorwaarde is niet hetzelfde als alleen name = @name, wat het de DBMS moeilijk maakt om de index eenvoudig te gebruiken.

Verhaal

In de klantenzoekdienst hebben we "flexibele filters" geïmplementeerd via het sjabloon (@par IS NULL OF Veld = @par), en naarmate het aantal bestellingen groeide, daalde de zoek snelheid van seconden naar minuten — de indexen werkten niet meer, omdat de optimizer geen specifieke waarde kon bepalen.

Verhaal

In het e-commerce project verzamelden we de filtering via dynamische SQL zonder parameters, waarbij waarden rechtstreeks werden ingevoerd. Injecties maakten het mogelijk voor gebruikers om lijsten van alle klanten te verkrijgen, omdat de filter kwetsbaar was — wachtwoorden moesten dringend worden veranderd.

Verhaal

BI-rapporten werden gebouwd via een geparametriseerd sjabloon zonder rekening te houden met het feit dat OR-voorwaarden de geïndexeerde scans uitsluiten. Bij miljoenen datasets “stagneerden” de rapporten totdat de filtering werd herschreven naar een optimale variant met verplichte voorwaarden en afzonderlijke logica voor verschillende combinaties van parameters.

Hoe implementeer je de voorwaardelijke logica voor dat filtering in SQL op de juiste en efficiënte manier, als de zoekparameters dynamisch worden ingesteld (bijvoorbeeld een webfilter met een willekeurige set voorwaarden)?

Antwoord.

Vragende vraag.