MySQL 5 : Les vues — (part 1/7)

novembre 23, 2008
Tags: ,

Le langage SQL acronyme de Structured Query Language (Langage Structuré de Requêtes), a été conçu pour gérer les données dans un SGBDR. A l’aide des DML (Data Manipulation Language ie les requêtes SELECT, INSERT, UPDATE, DELETE) il est possible de manipuler ces données qui sont stockées dans des tables. SQL nous propose une autre interface pour accéder à cette information: les vues.

Dans cet article, nous verrons comment créer et se servir des vues, puis avec quelques exemples pratiques, nous allons voir comment les utiliser le mieux possible.

Qu’est ce qu’une vue ?

Les vues sont des tables virtuelles issues de l’assemblage d’autres tables en fonction de critères. Techniquement les vues sont créées à l’aide d’une requête SELECT. Elles ne stockent pas les données quelles contiennent mais conservent juste la requête permettant de les créer.

La requête SELECT qui génère la vue référence une ou plusieurs tables. La vue peut donc être, par exemple, une jointure entre différentes tables, l’agrégation ou l’extraction de certaines colonnes d’une table. Elle peut également être créée à partir d’une autre vue.

Les vues sont souvent en lecture seule et ne permettent donc que de lire des données. Cependant MySQL permet la création de vues modifiables sous certaines conditions :

  • La requête qui génère la vue doit permettre à MySQL de retrouver la trace de l’enregistrement à modifier dans la ou les tables sous-jacentes ainsi que celle de toutes les valeurs de chaque colonne. La requête SELECT créant la vue ne doit donc pas contenir de clause DISTINCT, GROUP BY, HAVING… et autres fonctions d’agrégation. La liste complète est disponible dans la documentation de MySQL.
  • L’autre condition est que sa clause ALGORITHM ne doit pas être de valeur TEMPTABLE. Nous reviendrons sur ce point.

A quoi servent les vues ?

Les vues peuvent être utilisées pour différentes raisons, elles permettent de :

  • Contrôler l’intégrité en restreignant l’accès aux données pour améliorer la confidentialité
    • Partitionnement vertical et/ou horizontal pour cacher des champs aux utilisateurs, ce qui permet de personnaliser l’affichage des informations suivant le type d’utilisateur.
  • Masquer la complexité du schéma
    • Indépendance logique des données, utile pour donner aux utilisateurs l’accès à un ensemble de relations représentées sous la forme d’une table. Les données de la vue sont alors des champs de différentes tables regroupées, ou des résultats d’opérations sur ces champs.
  • Modifier automatiquement des données sélectionnées (sum(), avg(), max(),…)
    • Manipuler des valeurs calculées à partir d’autres valeurs du schéma.
  • Conserver la structure d’une table si elle doit être modifiée
    • Le schéma peut ainsi être modifié sans qu’il ne soit nécessaire de changer les requêtes du côté applicatif.

Les droits nécessaires

Pour créer une vue l’utilisateur doit avoir le droit CREATE VIEW. Il faut également avoir la permission de sélectionner toutes les colonnes qui apparaissent dans la commande SELECT spécifiant ce qu’est la vue.

De plus si la clause REPLACE est utilisée, le droit DROP est également nécessaire.

Le droit SHOW VIEW donne la possibilité d’exécuter la commande SHOW CREATE VIEW. Cette commande permet d’obtenir les informations de création d’une vue. Une autre façon d’obtenir ces informations est d’interroger la table view du schéma information_schema. Cette information sera exhaustive seulement pour les vues que vous avez créées.

(à suivre… syntaxe d’une vue)

8 Responses to “MySQL 5 : Les vues — (part 1/7)”

  1. merci du renseignement je n’avais jamais réussi a modifier une vue. Apparemment c’est simplement que les faisait trop « tordu »
    une question a laquelle j’aimerais avoir la réponse, peut étre dans un autre article : au niveau des performances comment fonctionne une vue? Est elle mise a jour a chaque changement de la source ou uniquement lorsqu’on essai d’y accéder?
    Merci d’avance.

  2. La vue peut être vue 🙂 comme une requête stockée, par conséquent la mise à jour ne ce fait que lorsque l’on accède à la vue. autrement dit, on refait la requête. Niveau performances, il n’y a pas d’intérêts

  3. […]    Posted by: freshdaz   in MySQL Add Comment (<- précédent) […]

  4. Tout d’abord merci beaucoup pour ces renseignements sur les vues, j’ai enfin compris le fonctionnement de ces vues ^^.

    Toutefois petite question : dans mes requêtes de création j’ai du utilisé des count et des group by par la suite et jusqu’à présent cela n’a pas posé de problème.

    Après une journée de test, mes vues fonctionnent parfaitement, mais y a t’il un risque que ces clauses fassent exploser ma vue ?

    Merci d’avance et j’attends la suite avec impatience.

  5. Non pas de souci !
    En fait la vue ne stocke rien… si ce n’est ton SELECT. Autrement dit, les données restent dans la ou les tables sous-jacentes. Donc pas de risques d’explosions 🙂

  6. En faisant des tests j’ai remarqué qu’on peut faire un liaison entre une vue et « sa » table. Comment cela se passe-t-il au niveau système ?
    Quand on appelle la vue, est-elle chargée et devient donc indépendante de son « origine » ? ce qui permet de faire un semblant de requête récursive…
    Avec une table et 3 vues de cette même table liées, le temps de réaction est très bon mais il est vrai que je n’ai que 4000 entrées dans cette table
    Merci

  7. Bonjour,
    je ne suis pas sure de bien comprendre ta question. Je vais cependant tenter d’y répondre. Une vue est en fait une requête SELECT stockée. Faire une requête sur la vue, revient donc à exécuter totalement ou partiellement ce SELECT sur la (ou les) table(s) sous-jacente. Elle ne stocke pas de données elle dépend donc de la (ou les) table(s) sous-jacente.

  8. Je vais essayer d’expliquer :
    J’ai une table de titres de livre qui contient un identifiant livre, le titre et le niveau du titre, 1 pour le titre principal et 2 pour le sous-titre.
    Si je fais un select des titres du livre 1, j’aurai deux lignes (s’il y a un sous-titre).
    Maintenant je fais une vue T1 des titres niveau 1 et une vue T2 des titres niveau 2.
    Si je fais un select de T1 JOIN T2 pour le livre 1, j’ai une ligne et 2 colonnes ce qui est beaucoup plus facile à traiter !

    Ma question était donc :
    mysql stoque-t-il temporairement le résultat des deux vues au moment de leur appel pour ensuite faire le select entre les deux vues ?