Performance de sous SELECT sur une Vue depuis une procedure Stockée

Bonjour
J'ai une procédure stockee qui fait une requete comme celle ci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SELECT CHAMP1 WHERE ID=@PARAM1 AND LI_ENT_ID IN ( SELECT ASSO_ID FROM V_ASS_COM_LIG_INT WHERE (ASSO_ID = @ENT_ID OR COM_ID = @ENT_ID OR LIG_ID = @ENT_ID OR INT_ID = @ENT_ID OR FED_ID = @ENT_ID) AND ASSO_ETAT_ID <> '5' ) )

---

or V_ASS_COM_LIG_INT est une Vue
Cela optiliserait t'il mon temps de traitement si je cree un champ calculé dans la vue correspondant au WHERE ou NON ?

Bonjour,
Pour moi ça ne changera pas grand chose, vu que SqlServeur devra de toute façon lire les données pour calculer la valeur de la colonne.
Mais le meilleur moyen de le savoir est de faire le test.

Tu peux aussi demander le plan d'exécution avec et sans la colonne calculée, et comparer les deux.

Est-ce qu'on peut avoir la définition de la vue ? Il y a peut-être quelque chose à faire de ce côté (en dehors de la colonne calculée).

Tatayo.

et avec un jointure ?

Une jointure pourrait modifier le résultat, par exemple si la vue renvoie plusieurs lignes pour un @ENT_ID.

Par contre on peut remplacer le IN par un EXISTS, mais je ne sais pas si ça a un impact sur la performance de la requête.

Tatayo.

Le problème est l'absurdité de ces OR. Sans doute le résultat d'une mauvaise modélisation.... Peut être absence d'héritage ? Dans tous les cas les performances courent vers la catastrophe...

A +

C'est visiblement un test d'existence.
Auquel cas il faut utiliser EXISTS, n fois si n tables, plutôt que IN.
De plus, il faut que la host variable soit de même type et de même longueur que la colonne pour qu'un index soit éligible.
Comme dans la requête présentée, la même host variable est utilisée pour comparer avec plusieurs colonnes, il y a un risque (ex : identifiant de type integer dans une table et small integer dans une autre)

SQLpro: c'est un peu ce que j'avais en tête, c'est pour ça que je demande la définition de la vue.
Peut-être que la/les tables mises en jeu sont correctement modélisées, et que la requête pourrait être mieux écrite sans passer par cette vue.

Tatayo.