Création de vues matérialisées

Server 2000 », à  l’adresse http://support.microsoft.
com/default.aspx?scid=kb ; [LN] ; 270054 .) Les optimiseurs
des autres éditions ne prennent pas en compte les vues
indexées lors du développement d’un plan de requête, à  moins
d’employer l’indicateur de requête WITH(NOEXPAND).
Pour illustrer ce comportement, procédez comme
suit dans SQL Server 2000 Edition Standard ou Edition Personnelle:

1. Ouvrez la console Enterprise
   Manager.

2. Accédez à  la base de données
   Northwind.

3. Cliquez avec le bouton droit de
   la souris sur Northwind et sélectionnez
   View, Taskpad.
   
4. Dans Taskpad, sélectionnez
   l’onglet Table Info et analysez
   l’affichage.

5. Ouvrez l’Analyseur de requêtes
   (Query Analyzer) et utilisez
   Northwind.

6. Servez-vous de l’un des listings
   de cet article pour créer une
   vue indexée.
   
7. Utilisez la combinaison de
   touches ALT-TAB pour revenir à 
   Enterprise Manager et actualisez
   l’écran de Taskpad.

La vue indexée créée doit s’afficher
avec les informations sur les
besoins en espace, au niveau de la
liste des tables utilisateurs dans la
base de données. Cette vue est désormais
permanente. Elle utilise de
l’espace dans la base de données et
des cycles processeur pour maintenir
la synchronisation entre les données
de l’index et celles des tables.

Dans la mesure où l’optimiseur
de requêtes de SQL Server 2000
Edition Standard n’utilisera pas la
vue indexée sans des instructions
spéciales dans la requête utilisateur
(à  savoir, WITH (NO EXPAND) dans
la clause FROM), rien ne compensera
l’utilisation additionnelle de
ressources. Par conséquent, si vous
n’exécutez pas SQL Server 2000
Edition Entreprise (ou Développeur)
et si vous souhaitez vous servir
de la vue indexée, vous devrez
forcer l’optimiseur de requêtes à  le
faire.

Vous construisez une vue indexée
en commençant par créer une vue normale, mais en ajoutant l’expression WITH SCHEMABINDING,
comme le montrent les trois premiers listings.
La liaison de schéma verrouille les schémas de tables sous-jacentes
ou les structures, empêchant ainsi les modifications
sur la table susceptibles de rendre orpheline la vue indexée.
Vous ne pouvez pas modifier une table sous-jacente si cela
risque d’invalider la vue. En cas de modification nécessaire
du schéma de table, vous devez d’abord supprimer la vue indexée,
puis la récréer une fois les modifications apportées au
schéma en question.

L’étape suivante du processus de matérialisation consiste
à  créer un index ordonné en clusters unique sur la vue. Cette
opération requiert un identificateur unique sur la vue, d’où
le besoin de bien connaître vos données.

Comme le montre le code du listing 2, j’ai dû inclure
TerritoryID et non seulement TerritoryDescription dans la requête
sur la vue car TerritoryDescription
n’est pas un identificateur unique. Le
code crée l’index ordonné en clusters
unique sur une concaténation de TerritoryID
et de EmployeeID. La colonne
EmployeeID n’est pas à  proprement parler
unique dans l’ensemble de résultat de
la vue. La combinaison de EmployeeID et
de TerritoryDescription ne produit pas
non plus une chaîne unique car TerritoryDescription
ne peut pas faire office de clé ; en effet cette
colonne contient des doublons. Vous devez inclure
TerritoryID dans la requête sur la vue, puis combiner
TerritoryID et EmployeeID afin de former un identificateur
unique pour la création de l’index.