Les vues

CREATE VIEW et DROP VIEW : la vue comme requête enregistrée et non comme copie, ses usages (simplifier, protéger, isoler du schéma), vue modifiable ou non, WITH CHECK OPTION et vue matérialisée.

  • 22 cartes
  • 5 thèmes
  • Gratuit

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Vue : de quoi s'agit-il ?

    Voir la réponse

    Requête SELECT enregistrée dans la base sous un nom : on l'interroge comme une table, mais elle ne stocke aucune ligne, son résultat est recalculé à chaque lecture.

    CREATE VIEW v_sf AS SELECT … FROM film WHERE genre = 'SF' : après un INSERT dans film, un nouveau film de SF apparaît aussitôt dans v_sf, sans rien synchroniser.

  • La table film contient trois films de SF : Dune, Alien et Matrix. Que rend le dernier SELECT ?

    ```sql
    CREATE VIEW v_sf AS
    SELECT titre FROM film WHERE genre = 'SF';
    INSERT INTO film VALUES (7, 'Interstellar', 'SF', 169, 2014);
    SELECT titre FROM v_sf;
    `

    • Les quatre films de SF, Interstellar compris
    • Les trois films de SF d'avant l'INSERT
    • Une erreur : la table a changé sous la vue
    • Seulement Interstellar, la ligne ajoutée
    Voir la réponse

    Les quatre films de SF, Interstellar compris

    La vue n'est qu'une requête : SELECT titre FROM v_sf relance son SELECT sur film, INSERT compris. Aucune copie n'a besoin d'être refaite.

  • Une vue ne stocke que … : les lignes sont lues dans … à chaque interrogation.

    Voir la réponse

    Une vue ne stocke que sa requête : les lignes sont lues dans les tables de base à chaque interrogation.

    C'est pourquoi une vue est toujours à jour et ne prend presque pas de place. C'est aussi pourquoi une vue lourde est recalculée à chaque lecture.

  • Vue matérialisée : de quoi s'agit-il ?

    Voir la réponse

    Requête dont le résultat est stocké sur disque comme une table : la lecture est rapide, mais les données ne suivent les tables de base qu'au moment du rafraîchissement.

    Dans PostgreSQL : CREATE MATERIALIZED VIEW …, puis REFRESH MATERIALIZED VIEW … pour recalculer. On y gagne en vitesse, on y perd en fraîcheur.

  • Cinq rapports recopient la même requête de 40 lignes (trois jointures et un calcul de marge). La règle de calcul vient de changer. Que faire pour ne plus avoir à la corriger à cinq endroits ?

    • Copier son résultat dans une table, à remettre à jour à la main chaque semaine
    • La ranger dans une vue lue par les cinq rapports
    • Remplacer les jointures par un SELECT * pour raccourcir la requête recopiée
    • Donner le même alias à la requête dans chacun des cinq rapports qui la recopient
    Voir la réponse

    La ranger dans une vue lue par les cinq rapports

    Une vue donne un nom unique à la requête : la règle s'écrit une fois, et les cinq rapports la lisent comme une table. Une copie dans une table dérive dès que les données changent.