Une introduction aux vues indexées

SQL Server prend en charge les vues depuis ses toutes premières versions. Une
vue est schématiquement une instruction SELECT enregistrée qui agit comme un filtre.
Supposons par exemple que l’on dispose d’une grande table contenant les enregistrements
de tous les clients de l’entreprise, et que quelques fois seuls les noms et les
numéros de téléphone des clients possédant le même code postal que vous, vous
intéressent. On pourrait créer une vue semblable à  celle-ci :

CREATE VIEW local_customers
AS
SELECT name, phone_number
FROM big_customer_list
WHERE zip = ‘98370’

A présent, on peut accéder à  cette vue comme s’il s’agissait d’une table, mais
sans avoir besoin de l’espace de stockage distinct associé à  une table. A chaque
fois qu’une requête fait référence à  la vue, SQL Server intègre le code définissant
la vue à  toute autre condition spécifiée. Ensuite, SQL Server optimise, compile
et exécute la requête résultante. En utilisant quelques-uns des mécanismes spéciaux
de mise en mémoire cache de SQL Server 7.0, la base de données peut être capable
de réutiliser le plan, sans que cela soit aussi probable qu’avec les procédures
cataloguées de SQL Server.
Les vues présentent deux avantages principaux. D’abord, elles simplifient l’écriture
des requêtes parce qu’elles n’exigent pas d’accéder directement aux tables, et
que souvent, elles contiennent déjà  des restrictions, calculs, agrégations, et
jointures (ce qui dispense d’avoir à  retaper les conditions). Ensuite, les vues
permettent de mettre en oeuvre un mécanisme de sécurité, et d’octroyer des droits
d’accès aux utilisateurs pour une vue particulière des données d’une table et
non à  l’intégralité de la table.

Une vue ne contient aucune donnée sauvegardée : il s’agit simplement d’une requête
sauvegardée. Par conséquent, le contenu d’une vue est dynamique. Si on ajoute
des enregistrements à  une table ou qu’on modifie les valeurs des données, la vue
affichera les informations mises à  jour. Le revers de la médaille, c’est que si
la vue contient des calculs basés sur les colonnes de la table, SQL Server doit
effectuer ces calculs à  chaque fois qu’un utilisateur accède à  la vue. En outre,
pour faciliter le traitement de la requête, la base de données ne peut pas utiliser
d’index sur une colonne impliquée dans un calcul.
Prenons une vue type, qui affiche le jour de la semaine auquel les commandes ont
été passées. La table de base possède une colonne Orderdate, mais supposons que
l’on souhaite également extraire des informations concernant les commandes. Créez
par exemple une vue comme ceci :

USE northwind
GO
CREATE VIEW OrderDates
AS
SELECT orderId, Day = datepart(month, Orderdate), Orderdate, ShipName, ShipCity,
ShipPostalCode
FROM Orders

On pourra alors utiliser la vue pour extraire toutes les commandes passées en
décembre (pour analyser l’augmentation du chiffre d’affaire de l’entreprise pendant
les fêtes), mais aucun index ne permettrait de trouver ces enregistrements. Un
index sur la colonne Orderdate localiserait les enregistrements par date exacte,
mais pas par le biais du mois auquel la commande a été passée.
Avec les vues indexées de SQL Server 2000, on peut à  présent construire un index
clusterisé sur une vue. Un index clusterisé est le seul type d’index SQL Server
qui contienne des données ; l’index clusterisé sur une vue contient toutes les
données constituant la définition de la vue. Dès que l’on crée cette index clusterisé,
la vue est matérialisée. En d’autres termes, SQL Server alloue un espace de stockage
pour elle. On peut alors traiter la vue comme une table, construisant de multiples
index non clusterisés sur elle (j’ai basé les explications et les exemples suivants
sur SQL Server 2000 EAP4 (Early Adopters Program) build 047, une version intermédiaire
entre la bêta 1 et la bêta 2).