182
Chapitre 6. Utilisation des index
contrôlé par le système. Dans les cas de volumes plus petits, en général des index
bien placés sur les tables sous-jacentes suffisent.
À partir de SQL Server 2005, les vues indexées sont prises en charge par l’édition Standard. Une fonctionnalité supplémentaire est présente dans l’édition Entreprise : l’optimiseur
de requête peut choisir d’utiliser un index sur une vue, même si la requête ne mentionne pas
explicitement la vue, mais simplement une table sous-jacente et que l’optimiseur trouve un
intérêt supérieur à utiliser cet index.
Votre index doit être créé avec certaines options de session qui garantissent la
consistance des données de la vue :
• ANSI_NULLS ON (aussi à la création de la table) ;
• QUOTED IDENTIFIER ON, et quelques autres options (voir les BOL) ;
• La vue doit avoir été créée avec l’option WITH SCHEMABINDING (ce qui la lie à la
structure des tables sous-jacentes, de sorte que les modifications de structure
de celles-ci sont protégées) ;
• Les indicateurs de table sont interdits, on ne peut donc forcer un index, ou un
niveau d’isolation, dans la requête ;
• Les fonctions référencées dans la vue doivent être déterministes (elles doivent
toujours retourner la même valeur, à données égales).
Ces options forcent simplement le retour de la vue à être consistant, donc
indexable. Les options telles que SET ANSI_NULLS doivent être placées pour toutes les
sessions qui requêtent la vue, ou modifient les données sous-jacentes, afin que SQL
Server puisse garantir que le résultat du SELECT de la vue est toujours le même. Cette
condition peut être contraignante dans un environnement où vous ne maîtrisez pas
tous les points d’entrées, et notamment avec des applications qui utilisent des bibliothèques d’accès aux données anciennes, comme ODBC.
Si vous utilisez PHP sous Windows, Microsoft a développé un pilote spécifique, téléchargeable à partir de ce lien : http://www.microsoft.com/sql/technologies/php/.
La première étape est de créer un index clustered unique sur la vue, qui va la
matérialiser. L’unicité est nécessaire, vous devez donc trouver un moyen de retourner
une colonne ou un jeu de colonnes unique dans votre vue.
Voici un exemple de création de vue, et d’utilisation par l’optimiseur, même en
mentionnant seulement la table sous-jacente (nous sommes en édition Developer,
qui correspond aux fonctionnalités de l’édition Entreprise) :
CREATE VIEW Person.SomeContacts
WITH SCHEMABINDING
AS
SELECT ContactID, FirstName, LastName
FROM Person.Contact
WHERE LastName LIKE '%Ad%'
Chapitre 6. Utilisation des index
contrôlé par le système. Dans les cas de volumes plus petits, en général des index
bien placés sur les tables sous-jacentes suffisent.
À partir de SQL Server 2005, les vues indexées sont prises en charge par l’édition Standard. Une fonctionnalité supplémentaire est présente dans l’édition Entreprise : l’optimiseur
de requête peut choisir d’utiliser un index sur une vue, même si la requête ne mentionne pas
explicitement la vue, mais simplement une table sous-jacente et que l’optimiseur trouve un
intérêt supérieur à utiliser cet index.
Votre index doit être créé avec certaines options de session qui garantissent la
consistance des données de la vue :
• ANSI_NULLS ON (aussi à la création de la table) ;
• QUOTED IDENTIFIER ON, et quelques autres options (voir les BOL) ;
• La vue doit avoir été créée avec l’option WITH SCHEMABINDING (ce qui la lie à la
structure des tables sous-jacentes, de sorte que les modifications de structure
de celles-ci sont protégées) ;
• Les indicateurs de table sont interdits, on ne peut donc forcer un index, ou un
niveau d’isolation, dans la requête ;
• Les fonctions référencées dans la vue doivent être déterministes (elles doivent
toujours retourner la même valeur, à données égales).
Ces options forcent simplement le retour de la vue à être consistant, donc
indexable. Les options telles que SET ANSI_NULLS doivent être placées pour toutes les
sessions qui requêtent la vue, ou modifient les données sous-jacentes, afin que SQL
Server puisse garantir que le résultat du SELECT de la vue est toujours le même. Cette
condition peut être contraignante dans un environnement où vous ne maîtrisez pas
tous les points d’entrées, et notamment avec des applications qui utilisent des bibliothèques d’accès aux données anciennes, comme ODBC.
Si vous utilisez PHP sous Windows, Microsoft a développé un pilote spécifique, téléchargeable à partir de ce lien : http://www.microsoft.com/sql/technologies/php/.
La première étape est de créer un index clustered unique sur la vue, qui va la
matérialiser. L’unicité est nécessaire, vous devez donc trouver un moyen de retourner
une colonne ou un jeu de colonnes unique dans votre vue.
Voici un exemple de création de vue, et d’utilisation par l’optimiseur, même en
mentionnant seulement la table sous-jacente (nous sommes en édition Developer,
qui correspond aux fonctionnalités de l’édition Entreprise) :
CREATE VIEW Person.SomeContacts
WITH SCHEMABINDING
AS
SELECT ContactID, FirstName, LastName
FROM Person.Contact
WHERE LastName LIKE '%Ad%'