Discussion :

[Trady]

Bonjour,

Faut-il mieux privilégier plusieurs vues avec le moins de colonnes possibles, ou une seule par exemple avec de nombreuses colonnes ?

Exemple:

TABLES
Table 1 : colonne A et B
Table 2 : colonne C et D
Table 3 : colonne E et F
Table 4 : colonne G et H


VUES

View ABC = columns A, B et C
View CDE = columns C, D et E
View CFGH = columns C, F, G et H

ou

View REGROUPEMENT = columns A, B, C, D, E, F, G et H

Cordialement.

[StringBuilder]

Je dirais que tout dépends des jointures effectuées entre les tables.

En effet, INNER JOIN et OUTER JOIN n'auront pas le même impact sur le plan d'exécution de la vue si lors de l'interrogation vous ne lisez pas les colonnes de certaines tables.

Mais en règle générale, je dirais que :
- N'hésitez pas à mettre plus de colonnes des tables déjà existantes dans les vues.
- Évitez de faire des vues qui font de multiples jointures si c'est pour ne pas exploiter le résultat de ces jointures.

En effet :

Table 1 : colonne A et B
Table 2 : colonne C et D
Table 3 : colonne E et F
Table 4 : colonne G et H

Devient :

CLIENT : colonne ID et NOM
COMMANDE : colonne CLIENT_ID et NUMERO
LIGNE_CDE : colonne CDE_ID et PRODUIT_ID
PRODUIT : colonne ID et NOM

Si vous interrogez votre vue "REGROUPEMENT" pour avoir la liste :
- des clients : vous aurez plein de doublons, et une lecture parfaitement inutile des 4 tables
- des commandes : idem
- des lignes de commandes : une lecture inutile des 4 tables, mais pas de doublon (youpi)
- des produits : idem les deux premiers

Si vous interrogez CDE pour connaître le numéro de commande de chaque ligne de commande, c'est parfait. Mais pourquoi ne pas récupérer aussi l'identifiant du produit dans la vue ? Ça ne coûtera absolument rien de plus au moteur SQL, et vous évitera de faire une jointure inutile sur la table des lignes de commandes pour récupérer cette donnée en plus.

[Trady]

- N'hésitez pas à mettre plus de colonnes des tables déjà existantes dans les vues.

Merci StringBuilder, mon interrogation portait sur ce point.