[SQL] parameter = NULL in where clause

[107mb]

ik gebruik binnen een rapport een sql query (SQL server). Deze query wordt gevuld met parameters.

SQL:

select * 
from tabel
where a = @p1
and b = @p2
and c = @p3

Er bestaan situaties dat een van de parameters niet gevuld wordt. Dit is gewenst gedrag. Ik zoek dus een manier om bijvoorbeeld de c uit te schakelen. Op het moment dat @p3 leeg is, moet deze dus uitgeschakeld worden.

Ik heb begrepen dat wildcases niet mogelijk zijn in T-sql.
Daarnaast heb ik zitten stoeien met case. Kan ik dit gebruiken? Zo ja, wat kan ik bij then invullen?

SQL:

AND c= CASE when isnull(@p3)
then ....???....
else @p3
end

wie heeft er een briljant idee?

[BSTNjitRam]

Zorg gewoon dat de expressie altijd TRUE oplevert wanneer een parameter NULL is
Voor @p3 wordt dat dus:

107mb schreef op maandag 02 april 2012 @ 15:41:

SQL:

select * 
from tabel
where a = @p1
and b = @p2
and (@p3 is null or c = @p3) 

[ Voor 4% gewijzigd door BSTNjitRam op 02-04-2012 15:45 ]

[107mb]

dit is dus het briljante idee!

bedankt voor deze simpele en doeltreffende oplossing!

[akakiwi]

Even een iets efficientere oplossing:

SQL:

select *  
from tabel 
where a = @p1 
  and b = @p2 
  and isnull(@p3, c) = c;

[DEiE]

Mag ik vragen wáárom deze efficiënter is? Ik ben niet heel erg bekend in databasesystemen, maar de oplossing van BSTNjitRam lijkt mij efficiënter.

In zijn versie wordt er gekeken of @p3 null is, en zo nee, wordt er gekeken of c overeen komt met @p3.
In jouw versie wordt er gekeken of @p3 null is, zo nee wordt c ook vergeleken met @p3, zo ja, wordt c vergeleken met c. Ook al verwacht ik dat dit weggeoptimaliseerd wordt, zou dit toch juist minder efficiënt moeten zijn, omdat ie een extra test moet doen?

Zie dit trouwens op geen enkele manier als een aanval, ik ben daadwerkelijk geïnteresseerd in hoe dit werkt .

[MSalters]

De eerste veronderstelling is dat het uberhaupt een verschil maakt, wat me al onwaarschijnlijk lijkt. Het ziet eruit alsof beiden tot hetzelfde query plan leiden.

[DEiE]

Dat was inderdaad ook mijn verwachting. In de eerste query wordt de tweede check niet uitgevoerd als de eerste check true oplevert, en ik verwacht dat de compiler de c = c ook wegoptimaliseerd, waardoor het tot dezelfde query leidt.

[ACM]

DEiE schreef op dinsdag 03 april 2012 @ 08:57:
Dat was inderdaad ook mijn verwachting. In de eerste query wordt de tweede check niet uitgevoerd als de eerste check true oplevert, en ik verwacht dat de compiler de c = c ook wegoptimaliseerd, waardoor het tot dezelfde query leidt.

In algemene zin hangt het er wel van af of deze query prepared wordt en dan daarna niet meer opnieuw gecompileerd/geoptimaliseerd. Het kan zijn dat daardoor niet alle optimalisaties achteraf nog uitgevoerd (kunnen) worden, maar dat is uiteraard afhankelijk van het gebruikte database-product.

Het is echter wel verstandig om niet zomaar voetstoots aan te nemen dat als jij vindt dat het hetzelfde is, dat de database dat dan ook met je eens is

[DEiE]

ACM schreef op dinsdag 03 april 2012 @ 09:18:
Het is echter wel verstandig om niet zomaar voetstoots aan te nemen dat als jij vindt dat het hetzelfde is, dat de database dat dan ook met je eens is

Precies, en daarom was ik ook benieuwd waarom de ISNULL sneller zou zijn, omdat ik zelf altijd de andere methode gebruik. Op internet zijn er wel testjes te vinden waarbij ze beide methoden vergelijken, alleen daarbij is het verschil minimaal.

Ik was in dit geval gewoon benieuwd waarom de voorkeur naar de ISNULL zou gaan, omdat ik deze methode normaal nooit gebruik. Als er een situatie is waarbij de ISNULL de voorkeur heeft, kan ik deze immers in de toekomst gaan gebruiken.