Chapitre 12Projet SunuShop

Les vues — VIEW

CREATE VIEW, CREATE OR REPLACE VIEW, DROP VIEW. Pourquoi les vues (simplifier, sécuriser, standardiser, reporting). Limitations. 4 vues métier : v_catalog, v_orders_summary, v_monthly_revenue, v_stock_alerts.

Concepts Théoriques

Une vue est une requête SELECT sauvegardée sous un nom permanent. Au lieu de réécrire une jointure complexe de 15 lignes à chaque fois, vous créez une vue une fois et vous la requêtez ensuite comme une table normale. C'est un raccourci, un alias pour une requête complexe.

Créer et utiliser une vue

CREATE VIEW v_catalog AS SELECT p.name, p.price, c.name AS category FROM products p INNER JOIN categories c ON p.category_id = c.id WHERE p.is_active = TRUE;

Ensuite : SELECT * FROM v_catalog WHERE price < 10000 ORDER BY price; — exactement comme si v_catalog était une table.

Comment MySQL exécute une vue

Quand vous faites SELECT * FROM v_catalog WHERE price < 10000, MySQL remplace v_catalog par la requête qui la définit et exécute le tout. La vue ne stocke AUCUNE donnée — elle exécute la requête sous-jacente à chaque appel. C'est un raccourci syntaxique, pas un cache.

Conséquence : sur des tables volumineuses, interroger une vue est exactement aussi lent (ou rapide) que la requête elle-même. Les index sur les tables sous-jacentes s'appliquent — si products a un index sur category_id, la vue en bénéficie.

Pourquoi les vues sont indispensables en entreprise

1. Simplifier l'accès — Une jointure de 5 tables avec GROUP BY et CASE WHEN fait 20 lignes. L'équipe frontend fait SELECT * FROM v_orders_summary au lieu de copier/coller 20 lignes à chaque fois. Moins de code, moins d'erreurs.

2. Sécuriser les accès — Vous donnez à un comptable l'accès à v_monthly_revenue (qui montre le CA par mois) sans lui donner accès directement à la table customers (qui contient les emails et téléphones). En combinaison avec les GRANT du chapitre 14, c'est un outil de sécurité puissant : GRANT SELECT ON sunushop.v_monthly_revenue TO 'comptable'@'localhost';

3. Standardiser les requêtes — Si 5 développeurs écrivent chacun leur version d'une requête de CA, ils obtiendront 5 résultats légèrement différents (l'un oublie d'exclure les commandes annulées, l'autre calcule le total différemment). Avec une vue, tout le monde utilise la même requête validée.

4. Faciliter le reporting — Les managers accèdent aux KPIs via des vues dédiées, sans écrire de SQL.

Vues updatables vs non-updatables

Les vues simples (sans JOIN, GROUP BY, DISTINCT, sous-requête, UNION) sont updatables — vous pouvez faire INSERT, UPDATE et DELETE à travers la vue, et MySQL modifie la table sous-jacente.

Les vues complexes (avec JOIN, GROUP BY, agrégations, DISTINCT) sont en lecture seule. C'est le cas de toutes nos vues SunuShop. Tenter un INSERT sur v_orders_summary déclenche une erreur.

Modifier et supprimer

CREATE OR REPLACE VIEW v_catalog AS SELECT ...; — remplace la vue existante par une nouvelle définition. Si la vue n'existe pas, elle est créée.

DROP VIEW IF EXISTS v_catalog; — supprime sans erreur si elle n'existe pas.

ALTER VIEW v_catalog AS SELECT ...; — même effet que CREATE OR REPLACE.

Vues imbriquées — une vue qui requête une vue

Vous pouvez créer une vue qui utilise une autre vue : CREATE VIEW v_top_categories AS SELECT category, SUM(total_raw) AS ca FROM v_orders_summary GROUP BY category ORDER BY ca DESC LIMIT 5;

Attention : trop de niveaux d'imbrication rend le debug difficile et peut dégrader les performances (MySQL doit résoudre chaque vue en cascade).

Quand créer une vue vs une simple requête

Créez une vue quand : la requête est utilisée régulièrement (au moins 2-3 fois par semaine), par plusieurs personnes, et le résultat doit être identique à chaque fois. Ne créez PAS de vue pour une requête ad-hoc que vous n'utiliserez qu'une fois — c'est du bruit qui encombre le schéma.