1. #1
    Membre confirmé Avatar de Christophe Charron
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2005
    Messages
    883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2005
    Messages : 883
    Points : 595
    Points
    595

    Par défaut De l'utilité d'une vue ou d'un ensemble de vues vs une fonction

    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.
    Cordialement,
    Christophe Charron

  2. #2
    Rédacteur/Modérateur
    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 077
    Points : 3 499
    Points
    3 499
    Billets dans le blog
    5

    Par défaut

    Bonjour,

    Citation Envoyé par Christophe Charron Voir le message
    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.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  3. #3
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    2 934
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 2 934
    Points : 4 842
    Points
    4 842
    Billets dans le blog
    1

    Par défaut

    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.
    On ne jouit bien que de ce qu’on partage.

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 947
    Points : 39 336
    Points
    39 336
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Christophe Charron Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Membre confirmé Avatar de Christophe Charron
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2005
    Messages
    883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2005
    Messages : 883
    Points : 595
    Points
    595

    Par défaut

    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.
    Cordialement,
    Christophe Charron

Discussions similaires

  1. [V7] Une vue peut-elle hériter de plusieurs vues ?
    Par sovo dans le forum Odoo (ex-OpenERP)
    Réponses: 9
    Dernier message: 09/09/2014, 19h02
  2. Réponses: 0
    Dernier message: 20/03/2014, 11h45
  3. Réponses: 10
    Dernier message: 31/01/2011, 12h32
  4. [RCP] Initialiser une action en même temps que sa vue
    Par sly078 dans le forum Eclipse Platform
    Réponses: 1
    Dernier message: 19/05/2010, 09h10
  5. Une requete Sql au lieu de trois vues
    Par ensi7 dans le forum Langage SQL
    Réponses: 6
    Dernier message: 30/08/2007, 12h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo