Performance syntaxe sql [where ( @var= 0 or ( @var != 0 and Champ = @var ) )]

Bonjour,

Une question métaphysique.
J'utilise SQL Server (actuellement 2008R2) et j'ai pour habitude depuis plusieurs années d'utiliser cette syntaxe dans mes clauses where pour gérer le cas "tous ou une valeur précise" :

Code:

---

where ( @var= 0 or ( @var != 0 and Champ = @var ) )

---

Est ce optimal ou pas (utilisation des index, ...) ?
Si "non", auriez vous une autre solution ?

merci d'avance pour vos conseils
:ccool:

L'utilisation de l'opérator "OR" empêche l'utilisation d'un index.

Ici, une discussion dans laquelle une solution plus performante est proposée.

Merci pour la réponse et la référence au post.
Le problème => si il y a beaucoup de clause, le fait d'imbriquer les "IF .." ça devient hyper redondant ...

Dans ce cas, cela dépasse le domaine de mes compétences et passe la main aux vrais DBA qui parcours ce forum...

Désolé.

Pourquoi pas du sql dynamique ?

Le SQL Dynamique, je n'aime pas.
Je trouve ça pas clair et pas maintenable.

Une solution qui me vient à l'esprit =>
pour chaque variable, une petite variable de type table (@tableXXX) avec les valeurs (soit l'unique valeur, soit toutes)

et JOINter ou faire un IN dessus.

Vous préférez des perfs médiocres ?

A partir du moment on une requête doit changer en fonction d'un paramètre externe, je ne vois pas d'autre réponse que de rendre le SQL dynamique. D'autre part, alourdir la condition SQL d'un

Code:

---

( @var= 0 OR ( @var != 0 AND Champ = @var ) )

---

ne me semble pas plus clair ni maintenable que du SQL dynamique.

Pour la clarté et la maintenabilité du SQL dynamique, rien ne vous empêche de faire des fonctions helpers qui génèrent le bon SQL, vous y gagnerez en clarté et maintenabilité.

edit : d'autre part, vous mentionnez dans votre demande une solution optimale et vous la refusez pour une solution à base de table temporaire pour une simple condition :roll:

C'est un échange d'idée et d'avis, pas la peine de vous enflammer.

Si j'ai posé la question, c'est bel et bien que je me soucis des performances non ? et que je souhaite changer la méthode utilisée.

Je parlais de variable table (@table) et non de table temporaire (#..).

Pour le sql dynamique, j'ai donné mon point de vue. Si a perfs égale on peut l'éviter, alors je préfère.

Vous parlez de fonction helper, vous pourriez préciser ?

Désolé pour le ton, je suis aussi là pour donner mon avis et je voudrais pas paraître si enflammé ;).

Par helper j'entends une fonction qui retourne la chaine condition du SQL dynamique en fonction de la valeur de @var et de la colonne visée par la condition.

en langage naturel :

Code:

---

1 2 3 4 5 6

helper_conditionfacultative(valeur, colonne) SI valeur > 0 ALORS retourne '' SINON retourne 'AND ' + colonne + ' = ' + valeur FIN

---

Ainsi vous n'écrivez pas X fois le test qui permet de générer la condition ou pas en fonction de @var, vous appelez le helper.

Est ce possible de faire du SQL DYNAMIQUE dans une fonction ?

exemple :

Code:

---

1 2 3 4 5 6

CREATE FUNCTION fn_mafonction (@param1, @param2, ...) RETURNS int AS BEGIN return [MA REQUETE EN SQL DYNAMIQUE QUI CALCULE] END

---

http://www.codeproject.com/Articles/...ored-Procedure

Tu as un article là dessus proposé par SQLPro :
http://blog.developpez.com/sqlpro/p1...-re/#more10898

OK, merci pour vos réponses.

- Une question => comment utiliser du SQL Dynamique dans une FUNCTION ? En PROCEDURE, pas de problème. En FUNCTION , il me met ceci :

Code:

---

1 2	"Msg*557, Niveau*16, État*2, Ligne*1 Seules les fonctions et certaines procédures stockées étendues peuvent être exécutées à partir d'une fonction."

---

- Merci pour l'article, je vais regarder avec la syntaxe des CASE dans le WHERE plutôt que par des "OR". (les index sont bien préservés dans ce cas ?)