SELECT table SQL récupérée par une instruction IF

Question

Hella tous,

Ce que je veux faire quelque chose comme ça, je vais avoir une table SQL en fonction de mon paramètre,

DECLARE @find varchar(30) 
SET @find = 'no' 

SELECT * FROM 
(

    if @find = 'yes' 
    (
    SELECT * FROM myTable 
    WHERE ID= '5882' 
    ) 
    ELSE 
    (
    SELECT * FROM myTable 
    WHERE OLD_ID= '5882' 
    ) 

) X 

Ceci est juste un Le tableau simple que j'ai donné à titre d'exemple, ma vraie requête SQL est beaucoup plus grande et donc je ne pense pas que je puisse utiliser SQL dynamique dans cette requête. J'ai donc besoin d'un autre moyen.

Answer 1

Utilisez la « fonction recherchée CASE » comme ceci:

WHERE 
    CASE 
     WHEN @find = 'no' THEN ID 
     WHEN @find = 'yes' THEN OLD_ID 
     -- put an ELSE clause here 
     -- if you want to catch @find not being no or yes 
    END 
    = '5882' 

Answer 2

Vous pouvez utiliser EXEC pour exécuter une chaîne SQL. Vous devez faire attention aux citations.

DECLARE @column varchar(max); 
SET @column = 'OLD_ID' 

EXEC('SELECT * FROM myTable WHERE ' + @column + ' = ''5882''') 

Answer 3

Pour assurer que les plans d'exécution optimales, je recommande de créer des requêtes distinctes, et d'appeler celui qui convient selon le « @find ». par exemple. SPROC1 interrogerait sur ID SPROC2 interrogerait sur OLD_ID

Alors soit, changer votre code d'appel pour appeler le sproc approprié ou, si vous voulez juste pour passer @find en tant que paramètre, créer une 3ème sproc qui vient agit comme une redirection: SPROC3:

IF (@find = 'no') 
    EXECUTE SPROC1 
ELSE IF (@find = 'yes') 
    EXECUTE SPROC2 
ELSE 
    .... 

Le risque avec d'autres approches est la pollution du plan d'exécution dans lequel un plan est créé pour un chemin (par exemple @ find = « no »), puis lors d'un appel ultérieur vient avec @ find = 'yes' il finit par utiliser le plan d'exécution beaucoup moins approprié, ce qui entraîne des performances médiocres. En d'autres termes, au lieu d'utiliser un index sur ID, il se peut que vous utilisiez l'index sur OLD_ID qui n'est évidemment pas idéal (et vice versa).