Salve,
PiGi78 ha scritto:
Sinceramente starei sulla prima risposta che ti hanno dato, ovvero:
SELECT *
FROM Tabella
WHERE (@x=0 AND <campo> LIKE '%')
OR (@x!=0 AND <campo> IN @x)
Se poi incappi nel problema di performance che hanno segnalato (e ci può stare), puoi aggiungere l'opzione "RECOMPILE" in modo da far studiare al DB un nuovo piano di esecuzione.
In questo caso paghi sempre lo scotto dello studio del piano di esecuzione migliore, però eviti di incappare nel problema segnalato
qui il problema del RECOMPILE "non serve e non aiuta"... il solo fatto dell'OR implica piani NON ottimali in se', al di la' del sicuro utilizzo di SQL Server della short circuit evaluation...
il RECOMPILE puo' "aiutare" nel caso
IF @x > 0
SELECT a
ELSE
SELECT b
dove i il branch di codice eseguito varia completamente per il batch in corso... nel caso di sopra, invece l'OR non richiede un RECOMPILE in quanto comunque il piano generato NON sara' ottimale...
il "modo piu'" valido, in questo senso, e' "esterno" al chiamante...
cioe' che il client esterno, in base al valore "esterno" di @x, chiami la stored procedure A oppure B... ma questo sposta molto il lavoro di logica lato client...
quindi il secondo modo ottimale e' il branching interno alla stored procedure primaria come indicato da @sspintux,
if @x=0
exec dbo.spExecSelectWhereLike ....
else
exec dbo.spExecSelectWhereLikeIn ...
MA, e c'e' sempre un ma , c'e' il maggior "costo" di manutenzione di 3 stored procedures, come giustamente indica @Toki
nella pratica, se non fortemente penalizzante, e' uso comune il
WHERE (@x=0 AND <campo> LIKE '%')
OR (@x!=0 AND <campo> IN @x)
ma un giro di test (e non con il db di sviluppo) ce lo farei
ad ogni modo "ho visto cose che...", dove queste sottigliezze sono da considerarsi molto marginali
salutoni romagnoli
--
Andrea