Discussion :

[olivtone]

Hello a Tous

Débat chez nous sur les jointures sur les vues, car beaucoup de developpeurs aiment le faire pour la simplicité des requetes SQL

Moi Personnellement je trouve pas ca terrible au niveau Syntaxe SQL, et de plus cela pourrit mon Plan d'execution...

Quelle est votre avis sur la question ?

merci a vous et bonne journée

[François DORIN]

Moi Personnellement je trouve pas ca terrible au niveau Syntaxe SQL

Quel est le problème au niveau de la syntaxe ? Une vue, une table, c'est transparent au niveau de l'écriture d'une requête !

cela pourrit mon Plan d'execution

Ce n'est pas censé le faire. Quel SGBD utilises-tu ?
Il y a même mieux, avec les vues matérialisées ou indexées (la terminologie diffère selon le SGBD), l'optimiseur peut se servir de vues pour optimiser des requêtes qui ne les utilisent pas initialement !

Donc mon avis perso :
1) cela facilite la lecture et l'écriture des requêtes
2) cela peut optimiser les requêtes.
3) Une table peut être remplacée par une vue (et vice-versa). Du coup, en cas d'évolution du schéma de la BD, s'il faut garder une compatibilité, c'est tout gagant.

Donc, pour moi, vue = oui

[escartefigue]

1) cela facilite la lecture et l'écriture des requêtes
2) cela peut optimiser les requêtes.
3) Une table peut être remplacée par une vue (et vice-versa). Du coup, en cas d'évolution du schéma de la BD, s'il faut garder une compatibilité, c'est tout gagant.

Donc, pour moi, vue = oui

+1
et
4) permet de masquer certaines colonnes sensibles par exemple dans le cas d'un service publié accessible par d'autres briques que celle propriétaire de la table (rarement utilisé)
5) permet de simplifier l'application en livrant des colonnes calculées ou recombinées
etc...

[olivtone]

Oui mais si on appelle juste dans la jointure une colonne de la vue, et que en regardant de plus pres le code la vue

et on s’aperçoit que celle ci fait 47 jointures et met 3 minutes a s’exécuter, dans ce cas n'est ce pas plus simple de passer par les tables ?

Dans le plan d’exécution, si la vue fait appel a 7 tables différents, je vois les 7 tables appelés dans mon plan d’exécution, alors que si ma requête tapait sur la table et non sur la vue, mon plan d’exécution serait beaucoup

plus simplifié...

[SQLpro]

Oui mais si on appelle juste dans la jointure une colonne de la vue, et que en regardant de plus pres le code la vue

et on s’aperçoit que celle ci fait 47 jointures et met 3 minutes a s’exécuter, dans ce cas n'est ce pas plus simple de passer par les tables ?

Dans le plan d’exécution, si la vue fait appel a 7 tables différents, je vois les 7 tables appelés dans mon plan d’exécution, alors que si ma requête tapait sur la table et non sur la vue, mon plan d’exécution serait beaucoup

plus simplifié...

Si votre modèle est parfaitement normalisé (respects des formes normales, au minimum 3e) vos données atomique et :

• aucun null
• aucune redondance
• la modif d'une information n'impacte pas plus d'une ligne

et que vous avez mis des contraintes, notamment d'IR, l'optimiseur de SQL Server est capable de supprimer certaines jointures inutiles....

A +