La même requête de rapport de vingt lignes a été copiée dans cinq tableaux de bord, et chaque copie a légèrement dérivé. L’un compte les commandes annulées, l’autre non. Les vues SQL résolvent ce problème en définissant cette logique une fois, dans la base de données, sous un nom clair.

Nous avons exécuté tous les exemples ci-dessous dans SQLite 3.50, et les résultats affichés proviennent de cette exécution. Les vues sont en SQL standard, mais des détails tels que la mise à jour via une vue, les vues matérialisées et la gestion des dépendances varient selon les bases de données, et nous les soulignons.

Qu’est-ce qu’une vue ?

Une vue est une instruction SELECT enregistrée dans la base de données avec un nom. Lorsque vous interrogez la vue, la base de données exécute cette requête enregistrée. Il agit comme un tableau de lecture, mais une vue normale ne contient pas sa propre copie des données.

Pensez à un filtre enregistré dans une feuille de calcul. Le filtre n’est pas une seconde copie de la feuille. C’est une façon de regarder les mêmes données, qui reflètent toujours les valeurs les plus récentes.

Les exemples de tableaux

CREATE TABLE customers (
  id INT PRIMARY KEY, name TEXT, city TEXT, email TEXT, credit_limit INT
);
CREATE TABLE orders (
  id INT PRIMARY KEY, customer_id INT, total INT, status TEXT
);

INSERT INTO customers VALUES
 (1,'Asha','Pune','asha@example.com',50000),
 (2,'Ben','Delhi','ben@example.com',20000),
 (3,'Chitra','Pune','chitra@example.com',80000);

INSERT INTO orders VALUES
 (101,1,1200,'paid'), (102,1,800,'paid'),
 (103,2,300,'pending'), (104,3,2500,'paid');

Créer une vue

Cette vue résume les commandes de chaque client. Il cache une jointure, un regroupement et une expression CASE derrière un nom simple :

CREATE VIEW customer_sales AS
SELECT c.id, c.name, c.city,
       COUNT(o.id) AS orders,
       COALESCE(SUM(CASE WHEN o.status = 'paid' THEN o.total END), 0) AS paid_total
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name, c.city;

Désormais, tout le monde peut l’utiliser, sans savoir comment il fonctionne :

SELECT * FROM customer_sales ORDER BY paid_total DESC;

-- 3 | Chitra | Pune  | 1 | 2500
-- 1 | Asha   | Pune  | 2 | 2000
-- 2 | Ben    | Delhi | 1 |    0

SELECT name, paid_total FROM customer_sales WHERE city = 'Pune';

-- Asha   | 2000
-- Chitra | 2500

Ben apparaît avec zéro, car la vue utilise un LEFT JOIN et un COALESCE. Des décisions comme celle-ci, prises une fois vues, sont exactement ce qui assure la cohérence des rapports. Pour actualiser votre compréhension de la gestion NULL, consultez Valeurs SQL NULL.

Les vues sont toujours actuelles

Puisqu’une vue normale exécute sa requête à chaque fois, les nouvelles données apparaissent immédiatement. Nous avons ajouté une commande payante pour Ben et interrogé à nouveau la vue :

INSERT INTO orders VALUES (105, 2, 900, 'paid');

SELECT name, paid_total FROM customer_sales WHERE name = 'Ben';

-- Ben | 900

Il n’y avait aucune étape d’actualisation ni aucune copie à synchroniser. C’est la principale différence par rapport à l’enregistrement des résultats de la requête dans une table distincte.

Masquer les colonnes

Les vues sont souvent utilisées pour exposer uniquement les colonnes dont une personne ou une application a besoin. Ici, les adresses e-mail et les limites de crédit sont omises :

CREATE VIEW public_customers AS
SELECT id, name, city FROM customers;

-- columns: id, name, city

Dans les bases de données disposant d’autorisations, telles que PostgreSQL, SQL Server et MySQL, vous pouvez accorder à un utilisateur de reporting l’accès à la vue mais pas à la table sous-jacente. SQLite n’a pas de compte d’utilisateur, nous ne pouvons donc afficher que la restriction de colonne elle-même. Traitez une vue comme une couche de protection. Les données sensibles nécessitent toujours un contrôle d’accès approprié, et certaines bases de données offrent une sécurité au niveau des lignes pour filtrer les lignes par utilisateur.

Performance : les vues ne sont pas un gain de vitesse

Un mythe courant veut que les vues accélèrent les requêtes. Une vue normale est remplacée par sa définition lorsque vous l’interrogez, la base de données fait donc le même travail que si vous aviez écrit vous-même la requête complète. Notre plan d’exécution montrait que la jointure et le regroupement de la vue étaient exécutés dans le cadre de la requête :

EXPLAIN QUERY PLAN SELECT * FROM customer_sales WHERE city = 'Pune';

-- CO-ROUTINE customer_sales
-- SCAN c ...
-- SEARCH o USING AUTOMATIC COVERING INDEX (customer_id=?) LEFT-JOIN
-- USE TEMP B-TREE FOR GROUP BY
-- SCAN customer_sales

Ainsi, une vue sur une requête lente reste une requête lente. La vitesse vient des index et d’une bonne conception des requêtes, comme indiqué dans Optimisation des requêtes SQL et Explication des index SQL. Méfiez-vous également des vues construites sur d’autres vues. Les couches d’imbrication permettent de rejoindre facilement la même grande table plusieurs fois sans s’en apercevoir.

Vues matérialisées

Une vue matérialisée stocke ses résultats, comme une table mise en cache. Les lectures sont rapides, mais les données sont aussi récentes que la dernière actualisation.

-- PostgreSQL
CREATE MATERIALIZED VIEW daily_sales AS
SELECT order_date, SUM(total) AS revenue FROM orders GROUP BY order_date;

REFRESH MATERIALIZED VIEW daily_sales;

Le soutien varie. PostgreSQL et Oracle disposent de vues matérialisées et SQL Server propose des vues indexées avec leurs propres règles. SQLite et MySQL n’en disposent pas, les utilisateurs utilisent donc un tableau récapitulatif régulier actualisé selon un calendrier. Nous n’avons pas exécuté l’exemple PostgreSQL pour cet article.

Pouvez-vous mettre à jour une vue ?

Cela dépend de la base de données et de la vue. Une simple vue sur une seule table, sans regroupement ni DISTINCT, peut souvent être mise à jour dans PostgreSQL, MySQL et SQL Server, et la modification est transmise à la table. Une vue avec des jointures ou des agrégats ne le peut généralement pas, car la base de données ne peut pas déterminer quelle ligne modifier.

SQLite n’autorise pas du tout les écritures directes dans les vues. Notre tentative a échoué :

INSERT INTO customer_sales (name) VALUES ('X');

-- cannot modify customer_sales because it is a view

Certaines bases de données prennent en charge les déclencheurs INSTEAD OF pour rendre une vue accessible en écriture, et beaucoup proposent WITH CHECK OPTION, qui arrête les écritures qui ne seraient pas visibles via la vue. En pratique, la plupart des équipes conservent les vues en lecture seule et écrivent dans les tables.

Dépendances et casse

Une vue dépend des tables à partir desquelles elle lit. Nous avons créé une vue sur une table, puis supprimé la table :

CREATE TABLE ghost AS SELECT 1 AS x;
CREATE VIEW v_ghost AS SELECT x FROM ghost;
DROP TABLE ghost;

SELECT * FROM v_ghost;
-- no such table: main.ghost

SQLite a autorisé la suppression et n’a échoué que plus tard, lorsque la vue a été utilisée. D’autres bases de données, telles que PostgreSQL, refusent de supprimer une table dont dépend une vue, à moins que vous n’ajoutiez CASCADE, qui supprime également la vue. Quoi qu’il en soit, renommer ou supprimer une colonne peut interrompre les vues, alors vérifiez-les dans vos tests de régression après les modifications du schéma.

Il existe également un piège subtil avec SELECT * dans une vue. Nous avons créé CREATE VIEW star AS SELECT * FROM customers, puis ajouté une colonne au tableau. Dans SQLite, la vue récupère la nouvelle colonne. D’autres bases de données, notamment PostgreSQL, développent la liste des colonnes lors de la création de la vue, de sorte que les nouvelles colonnes n’apparaissent pas. Alors listez explicitement les colonnes. Il documente la vue et se comporte de la même manière partout.

Gestion des vues

La suppression d’une vue supprime uniquement la requête enregistrée. Dans notre test, la table customers contenait toujours les trois lignes après la suppression de public_customers. Conservez les définitions de vue dans le contrôle de version avec vos migrations, afin que les modifications soient examinées comme n’importe quel autre code.

Vue vs CTE vs table

Erreurs courantes

• En attente d’une augmentation de vitesse. Une vue normale exécute sa requête à chaque fois.
• Utilisation de SELECT * dans les vues. Le comportement diffère entre les bases de données lorsque les tables changent.
• Imbrication profonde. Les vues construites sur des vues masquent les jointures coûteuses.
• Utilisation de ORDER BY dans une vue. L’ordre n’est pas garanti lorsque vous l’interrogez, alors triez dans la requête externe.
• Noms peu clairs. Un préfixe tel que v_, ou un nom clair comme customer_sales, aide.
• Oublier les vues lors des migrations. Testez-les après chaque changement de schéma.

Pour conclure

Les vues sont un moyen simple de donner une place à la logique importante dans la base de données. Utilisez-les pour maintenir la cohérence des rapports et masquer les colonnes inutiles, et non pour améliorer les performances. Pour commencer, recherchez une requête qui apparaît à plusieurs endroits de votre code, transformez-la en une vue avec des colonnes explicites et pointez vers elle chaque appelant.

Questions fréquentes

Continuez à apprendre