Discussion :

[Christophe Charron]

Bonsoir,
je souhaite trouver de la littérature pour étayer ce qui n'est qu'une conviction et/ou un vieux souvenir sur la non pertinence de systématiquement utiliser/créer des vues.

J'illustre :
un collègue, à la base non-informaticien ou du moins non écrivain SQL, a créé une dizaine de vues, certaines "basiques", c'est à dire ne faisant référence qu'à trois ou quatre tables chacune, puis d'autres faisant référence à ces vues et encore d'autres faisant références à ces dernières vues. Cela, a priori, parce qu'il lui était difficile de créer des requêtes avec de multiples alias sur les même tables.
Les vues "basiques" portent sur des tables qui sont assez souvent mouvements (ajout/modifs d'articles, clients, lignes de BL) sur des volumes significatifs.
Le traitement justifiant toute cette cavalerie est exécuté une fois par mois pour l'émission de la déclaration d'échange de biens (la DEB).

Je lui soutiens que pour un traitement aussi peu courant, il faudrait mieux créer une fonction, certes un peu "touchy", mais qui ne serait invoquée qu'une fois par mois plutôt que des vues qui sont constamment mises à jour, du moins chaque fois que des éléments constitutifs sont modifiés/ajoutés.
Ai-je raison? Ai-je tort ? Avec quels arguments puis-je soutenir mon point de vue?

D'avance, merci pour vos lumières.

[François DORIN]

Bonjour,

Je lui soutiens que pour un traitement aussi peu courant, il faudrait mieux créer une fonction, certes un peu "touchy", mais qui ne serait invoquée qu'une fois par mois plutôt que des vues qui sont constamment mises à jour

De quel type de vue parles-tu : des vues "classiques", ou des vues indexées ?

Pour les vues classiques, il n'y a pas de mise à jour des données puisque la requête n'est exécutée que lorsque la vue est utilisée.

Si les vues sont matérialisées, alors effectivement la mise à jour des vues a un coût qui, dans ton cas, est a priori non négligeable puisque beaucoup de mise à jour pour peu d'accès en lecture (une fois par mois).

Maintenant, pour les différences vues non matérialisées vs fonction table sans paramètre, les performances devraient être similaires si la requête derrière est la même.

[StringBuilder]

Le seul cas où les vues non indexées vont poser problèmes, c'est si elles font des traitements lourds (regroupement, fenêtrage, récursivité, etc.) inuties.

Par exemple, une vue qui calcule pour chaque salarié son niveau hiérarchique, la somme des salaires des subalternes et le nombre de commandes passées par l'ensemble de son service, on va éviter de l'appeler pour retrouver uniquement la liste des noms des salariés classés par ordre alphabétique.
=> L'optimiseur va bien tenter de simplifier le plan d'exécution au vue du résultat attendu, mais il n'est pas magicien non plus

Pour le reste, au contraire, on ne devrait "jamais" faire de CRUD directement dans les tables, mais toujours se baser sur des vues, même si elles sont de type "select * from ma vue", pour de simples raisons de :
- gestion des droits
- évolutivité

Par exemple, si j'ai une table "client", je crée une vue "v_clients".
=> Si demain je dois restreindre la liste des clients à ceux directement gérés par l'utilisateur connecté, j'ai juste ç révoker l'accès à la table à tout le monde, puis rajouter une clause where sans le code de ma vue "where client.responsable = SUSER_NAME()"

=> Aucune autre modification du code null part.

[SQLpro]

Bonsoir,
je souhaite trouver de la littérature pour étayer ce qui n'est qu'une conviction et/ou un vieux souvenir sur la non pertinence de systématiquement utiliser/créer des vues.

D'un point de vu formel les vues sont une nécessité. Elle constitue ce que l'on appelle le MED ou Modèle Externe de Données dont le but est de présenter et représenter l'information. Elle ne contiennent pas de données et sont de simples requêtes enregistrées que l'on peut utiliser comme une table (en lecture comme en mise à jour).

• Présenter, c'est à dire assurer une certaine couche de cosmétique purement sémantique.
• Représenter, c'est à dire filtrer, sécuriser, masquer certaines informations en fonction des différentes profils d'utilisateur.

Normalement les applications ne devrait jamais accéder directement aux tables et passer systématiquement par des vues ceci afin d'assurer une totale indépendance de la structure de la base au code client. En effet, en cas de modification de la structure d'une table (suppression ou ajout de colonne, découpage d'une table) les applications doivent être récrites. En revanche lorsque les applications n'accèdent qu'à des vues et jamais aux tables on peut remanier profondément la structure des tables, il suffit de modifier la vue pour la faire correspondre à nouveau aux données attendues par l'application pour que cette dernière reste inchangée !
Malheureusement le manque de formation des développeurs en général et la méconnaissance de l'usage des vues SQL qui en découle, font qu'ils ne les utilisent jamais ! Et c'est bien dommage.

J'illustre :
un collègue, à la base non-informaticien ou du moins non écrivain SQL, a créé une dizaine de vues, certaines "basiques", c'est à dire ne faisant référence qu'à trois ou quatre tables chacune, puis d'autres faisant référence à ces vues et encore d'autres faisant références à ces dernières vues. Cela, a priori, parce qu'il lui était difficile de créer des requêtes avec de multiples alias sur les même tables.
Les vues "basiques" portent sur des tables qui sont assez souvent mouvements (ajout/modifs d'articles, clients, lignes de BL) sur des volumes significatifs.
Le traitement justifiant toute cette cavalerie est exécuté une fois par mois pour l'émission de la déclaration d'échange de biens (la DEB).

Je lui soutiens que pour un traitement aussi peu courant, il faudrait mieux créer une fonction, certes un peu "touchy", mais qui ne serait invoquée qu'une fois par mois plutôt que des vues qui sont constamment mises à jour, du moins chaque fois que des éléments constitutifs sont modifiés/ajoutés.
Ai-je raison? Ai-je tort ? Avec quels arguments puis-je soutenir mon point de vue?

D'avance, merci pour vos lumières.

Et bien vous avez tort et cela pour trois raisons...

• La première je viens de vous la donner.
• La seconde c'est dans dans un monde ensembliste (les bases de données ont une forme quasi pure de mathématiques ensemblistes) utiliser des objets itératifs (c'est à dire agissant ligne à ligne et non plus manipulant globalement des ensembles de données) comme c'est le cas des fonctions, c'est l'assurance absolu de mauvaises performance...
• La dernière donnée par M. Dorin, c'est qu'il existe un type particulier de vues, les vues indexées (ou matérialisées) dont la particularité est de stocker des résultats pré-calculés afin d'éviter de parcourir trop de données. Bien qu'ils s'agisse d'une forme de redondance normalement prescrite dans la modélisation des bases de données relationnelles, ces dernières peuvent apporter un gain spectaculaire dans certains cas, notamment s'il existe des calculs d'agrégation. Pour information, vous pouvez jeter un coup d’œil à l'article que j'ai écrit ici et qui montre qu'une vue indexée va être 16 000 fois plus rapide que la lecture de la table....

A +

[Christophe Charron]

Merci à tous les trois pour la clarté de votre pédagogie.
Grâce à vos précisions, je sais déjà comment désormais orienter mon propos.
Je vais creuser de mon côté afin de bien comprendre les deux types de vues et d'essayer d'être pertinent dans leur utilisation.

Je lirai également, à tête reposée, l'article de Frédéric Brouard pour valider mes expérimentations.

Encore un grand merci.