Discussion :

[sacrejohn]

Bonjour, j'ai créer une procédures stockée qui me permet de retourner un résultat selon différentes critères de recherche.

Afin de filtrer mes donées selon ses différents critères, je suis obligé d'utiliser de nombreuses jointures. Ensuite pour filtrer concrétement mes données, je procédre ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
where
        (
               (@maVar is null)
               or
              (
                     (@maVar is not null)
                     and
                     (Critères de recherche)
              )
        )

J'ai cependant remarquer que même si ma variable est nulle, SQL va tout de même faire mon critère de recherche. Ce qui a pour conséquence de diminuer les performances. De même je me demande si faire toutes ses jointures qui ne servent pas forcément (en fonction des critères de recherche) ne diminuent pas les performances.

Je me demandais donc s'il n'était pas plus opportun de créer dynamiquement ma requête en fonction des critères puis de l'exécuter. Mais dans ce cas, il me semble de perdre tout l'intérêt des procèdures stockées.

Quelq'un a t il déjà mené quelques recherches dans ce sens ?

J'attends vos réponses.

[Fabien Celaia]

Non, un critère de recherche améliore les performances : une condition supplémentaire sujette à indexation peut éviter le scannage de table que fera nécessairement une requête sans condition.

[sacrejohn]

Je n'ai pas tout compris à ta réponse. Mais je me rends compte que je n'ai pas été très clair.

Dans mon critère de recherche, j'utilise un Identifiant. Cet identifiant provenait d'une jointure que je faisais sur une clé étrangère, sur laquelle, je n'avais pas mis d'indexe.

Soit :

Table A :

ClePrimaire : CP
CleEtrangere : CK
TableB tb
innner join tableA ta on
ta.CK = tb.(clé primaire de la table B)

where
(
(@maVar is null)
or
(
(@maVar is not null)
and
(ta.CK = .... Critères de recherche) <-- Ici, je me sers de ma clé etrangère
)
)



Dans ma requete je faisais ma jointure sur la clé étrangère et dans mon critère j'utilisais ma clé primaire.

N'ayant pas mis d'indexe sur ma clé étrangère, le fait de récupérer ma clé primaire était très long.

Pourtant je pensais que comme dans ma requete j'avais mis un "or" mon critère ne serait pas exectuté par SQL.

Aprés avoir mis un index sur ma clé étrangère, les performances de ma requete se sont grandement améliorés.

Mais cela ma fait reflechir, que le fait de récupérer cet Identifiant même si je n'en ai pas besoin ne ralentit pas ma requete (ce qui était le cas, le fait d'avoir oublier de mettre un index, me l'a bien montré.)

De plus, je me demande pourquoi, un index n'est il pas créer automatiquement lorsqu'on utilise une clé étrangère. Quelles peuvent être les inconvénients d'un index. Je sais que l'insertion est légérement ralentit, et que la taille de la base grossit, mais est ce les seuls désavanatages ?

Merci

[Fabien Celaia]

Un index est automatiquement mis sur une clé primaire car c'est l'unique méthode qu'a le SGBDR de forcer l'unicité. Cette unicité n'est pas nécessaire avec une clé étrangère, donc l'index non plus. Rien ne vous empêche de le créer (et c'est souvent fort utile). Le SGBDR n'a pas à le faire de lui-même, bien qu'un certain nombres d'outils de modélisation génèrent des indexes sur les clés étrangères, ce n'est pas une obligation.