Réponse

En SQL, il existe deux types de vues :

• Vues ordinaires (View) : tables virtuelles logiques. Elles ne stockent pas de données, une requête sur la VIEW génère à chaque fois une sous-requête sur les tables source.
• Vues matérialisées (Materialized View) : elles stockent physiquement le résultat de l'exécution de la requête dans une table distincte, qui est mise à jour périodiquement.

Les vues ordinaires sont pratiques pour abstraire la complexité, simplifier l'accès et combiner des données provenant de plusieurs sources. Elles n'accélèrent pas les requêtes, car elles se forment toujours à la volée.

Les vues matérialisées offrent un gain de performance pour les rapports complexes et l'analyse, où il est important de ne pas attendre les agrégations et les jointures à chaque fois. Elles doivent être actualisées manuellement ou selon un horaire pour que les données ne deviennent pas obsolètes.

Exemple d'une VIEW ordinaire :

CREATE VIEW active_users AS
SELECT id, name FROM users WHERE status = 'active';

Exemple d'une VIEW matérialisée (PostgreSQL) :

CREATE MATERIALIZED VIEW active_users_agg AS
SELECT country, COUNT(*) as cnt FROM users WHERE status = 'active' GROUP BY country;
-- Pour mettre à jour :
REFRESH MATERIALIZED VIEW active_users_agg;

Question piège

Peut-on mettre à jour les données dans une VIEW et comment cela dépend-il du type de VIEW ?

On pense souvent à tort que les VIEW sont totalement identiques aux tables en termes de mise à jour. EN RÉALITÉ :

• Les vues ordinaires permettent rarement des mises à jour : uniquement s'il n'y a pas de champs agrégés, groupés ou dérivés/calculés (et encore en l'absence de JOIN et de sous-requêtes).
• Les Vues matérialisées ne peuvent pas être mises à jour directement — seulement via REFRESH, sinon un décalage des données se produit.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire 1

Un rapport BI était construit via une VIEW ordinaire avec plusieurs JOIN et agrégats. Après une augmentation de la charge, le temps de génération du rapport est passé à plusieurs dizaines de minutes. Un analyste système a proposé une vue matérialisée, ce qui a instantanément réduit le temps à quelques secondes, car les données ont commencé à être stockées dans une table distincte.

---

Histoire 2

Un développeur, lors de la migration vers Oracle, a tenté de faire un UPDATE à travers une VIEW ordinaire, ce qui a provoqué l'erreur : "view with group by is not updatable". La raison était l'utilisation de GROUP BY dans la vue.

---

Histoire 3

Dans une entreprise, ils oubliaient de mettre à jour la vue matérialisée après l'importation de nouvelles données, ce qui a conduit à un décalage des rapports entre différents utilisateurs, car l'analyse travaillait avec de vieilles données provenant de cette VIEW. Après, un REFRESH automatique a été ajouté selon un horaire.