Version imprimable
Bonjour
J'utilise une vue complexe qui dans 90% des cas doit etre filtrée sur un champ NULL (WHERE champ is NULL)
Mais dans 10% je dois filtrer sur autre chose
Je pense donc a definir une premiere vue (Sans Filtre)
Et une autre vue qui ferais un simple select sur la premiere mais avec le Filtre
WHERE Champ IS NULL
Est-ce pertinent
Pas forcément, l'optimiseur sait simplifier l'écriture finale de la requête....
La seule légitimité de faire de nombreuses vues, y compris des vues de vues est simplement fonctionnelle !
A +
Merci SqlProCitation:
La seule légitimité de faire de nombreuses vues, y compris des vues de vues est simplement fonctionnelle !
C'est effectivement le but ici
- plusieurs application utilisent cette vue en mode filtré (WHERE CHAMP IS NULL)
- Mais certaines doivent avoir une visibilité complete
Donc pour ne pas ecrire entierement les deux vues l'idée est de faire la vue principale sans filtre et d'appliquer sur cette premiere vue une vue avec filtre
Mais comme cette vue sur vue sera la plus utilisée je me demandans si je n'allais pas de cette maniere allourdir les performances
L'alternative moins agréable a gerer c'est evidemment de creer deux vues identique avec et sans filtre ?
Bonjour,
Si vous êtes sous SQL Server 2008, et que le nombre de lignes pour lesquelles la colonne est à NULL est faible par rapport au nombre total de lignes de la table, pensez aux index filtrés ;)
@++ ;)
Bonjour Elsuket
Non c'est l'inverse ! J'ai 95% de NULL sur +/- 100.000 records (mais la vue qui produt ces lignes n'est pas triviale)
Comme le laissait entendre SQL Pro, vous ne souffrirez pas de perte de performance à employer une vue dans une autre vue.
Faite donc votre vue complète et faite une vue limité employant la précédente.
Votre code sera plus facile à lire et maintenir.
Citation:
Comme le laissait entendre SQL Pro, vous ne souffrirez pas de perte de performance à employer une vue dans une autre vue.
A ne pas exagérer tout de même....
Heu... la création du plan d'exécution prendra 0.02% de temps en plus pour atteindre une durée de 1 milliardième du temps d'exécution total ?Citation:
Envoyé par iberserk
On peut aussi conseiller de ne pas bouger le curseur de la souris pendant l'excécution.
Merci a tous
Citation:
Heu... la création du plan d'exécution prendra 0.02% de temps en plus pour atteindre une durée de 1 milliardième du temps d'exécution total ?
On attends tes mesures avec impatience:ccool:
Contredis moi quand j'exprime que la "perte" de performance ne serait autre que triviale. Car elle l'est, à ma connaissance.Citation:
Envoyé par iberserk
Je préfère apprendre : éclaire nous.
Je te charriais...Citation:
On attends tes mesures avec impatience
Evidemment elle sera triviale mais c'est vrai pour beaucoups de chose en exploitation de base de données...Citation:
Contredis moi quand j'exprime que la "perte" de performance ne serait autre que triviale. Car elle l'est, à ma connaissance.
Sur 2005, la limite d'imbrication est de 32 :
Citation:
Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).
Pour avoir du travailler sur des vues imbriquées, je conseillerais d'y aller mollo moderato sur les niveaux d'imbrication.
Quand tu passes une demi-heure pour comprendre que ce que fait la vue de niveau 10 est un select sur la vue initiale avec 3 champs de moins et une clause WHERE en prime, tu as VRAIMENT l'impression de perdre ton temps... :aie: