Créer une vue

NUMERIC_ROUNDABORT doit être désactivée (OFF).
Par défaut, les outils client SQL Server 2000 configurent toutes ces options à 
leurs valeurs correctes exception faite d’ARITHABORT. La manipulation des vues
indexées s’en trouve ainsi facilitée. Par mesure de sécurité, utilisez le paramètre
sp_configure afin de configurer un bit dans la valeur user options pour placer
ARITHABORT à  ON. Le code suivant récupère la valeur courante de user options dans
la table syscurconfigs. Ensuite, il utilise un opérateur logique OU pour activer
le bit approprié en plus de tous les autres bits activés précédemment :

use master
declare @value int
select @value = value from syscurconfigs
where config = 1534
set @value = @value | 64

exec sp_configure ‘user options’, @value
reconfigure

Notez que les options doivent être placées à  ces valeurs lorsqu’on crée la vue
indexée, lorsqu’on modifie toute table incluse dans la vue indexée, et lorsque
l’optimiseur décide d’utiliser la vue indexée comme partie d’un plan de requête.
On peut vérifier quelles options sont activées pour une connexion donnée en exécutant
la requête DBCC USEROPTIONS. On peut également utiliser la nouvelle propriété
de la fonction SESSIONPROPERTY pour tester si on a convenablement activé chaque
option (1 = ON, 0 = OFF) :

SELECT SessionProperty(‘NUMERIC_ROUNDABORT’)

Gardez à  l’esprit quelques recommandations supplémentaires lorsque vous créez
une vue. Premièrement, toutes les fonctions et expressions de la définition de
la vue doivent être déterministes. En règle générale, toute fonction qui, pour
les mêmes paramètres, peut retourner deux résultats différents dans deux invocations
distinctes est non-deterministe. Deux exemples évidents de fonctions non-deterministes
sont getdate() et rand(). La plupart des fonctions système sans paramètres, telles
que @@spid, @@servername et @@rowcount, sont également non-deterministes. Vous
serez probablement surpris de constater que datename() est également non-déterministe
; les valeurs qu’elle renvoie dépendent de la langue dans laquelle on a configuré
SQL Server avec sp_configure. La langue peut varier d’un utilisateur à  un autre
(même sur le même serveur et avec la même base de données) pour qu’un utilisateur
reçoive par exemple ses messages d’erreur en anglais, et qu’un autre les reçoive
en français. Datepart() est non-deterministe lorsque le premier paramètre est
DW (day of week, ou jour de semaine) parce que DW peut varier en fonction de la
configuration DATEFIRST. (La version finale de SQL Server Books Online – BOL –
pour SQL Server 2000 énumérera les fonctions qui sont ou ne sont pas déterministes).
En outre, toute vue contenant une colonne, constante ou expression de type float
dans sa définition est non-déterministe.

La deuxième contrainte à  laquelle il faut faire attention lors de la création
d’une vue est qu’il ne faut pas que la définition du schéma sous-jacent d’un objet
change. Pour empêcher la modification de la définition du schéma sous-jacent,
l’instruction SQL Server 2000 CREATE VIEW autorise l’option SCHEMABINDING. Quand
on spécifie with SCHEMABINDING, l’instruction SELECT définissant la vue doit inclure
les noms à  deux composants (owner.object) de toutes les tables référencées. On
ne peut ni retirer ni modifier les tables participant à  une vue créée avec la
clause SCHEMABINDING, à  moins de laisser tomber cette vue, ou de la modifier de
manière à  ne plus indiquer SCHEMABINDING. Dans le cas contraire, SQL Server génère
une erreur. Si un utilisateur lambda est propriétaire d’une table sur laquelle
on base une vue, on n’a pas nécessairement le droit de créer la vue avec SCHEMABINDING,
car cela empêcherait le propriétaire de la table de modifier sa propre table.
Le propriétaire de la table doit accorder aux autres utilisateurs les droits d’accès
REFERENCES pour que ceux-ci puissent créer une vue avec SCHEMABINDING.
Enfin, SQL Server 2000 limite la syntaxe utilisable dans une instruction CREATE
VIEW. La définition de la vue ne doit pas contenir les éléments suivants :

· TOP
· text, ntext, ou colonnes image
· DISTINCT
· MIN, MAX, COUNT(*), COUNT(), STDEV, VARIANCE, ou AVG
· SUM sur une expression potentiellement nulle
· une table derivée
· la fonction ROWSET
· une autre vue (on ne peut référencer que des tables de base)
· UNION
· sous-requêtes, jointures OUTER ou auto-jointures
· prédicats de recherche textuelle (CONTAIN ou FREETEXT)
· COMPUTE ou COMPUTE BY

Par ailleurs, si la définition de la vue contient une clause GROUP BY, il faut
inclure le nouvel agrégat COUNT_BIG(*) dans la liste SELECT. COUNT_BIG renvoie
une valeur de type BIGINT, le nouveau type de données qui est un nombre entier
de 8 octets. Une vue contenant GROUP BY ne peut pas contenir HAVING, CUBE, ROLLUP
ni GROUP BY ALL. Et toutes les colonnes GROUP BY ALL doivent apparaître dans la
liste SELECT.
Pour s’assurer que l’on a répondu à  toutes ces contraintes, on utilise la nouvelle
valeur de la fonction ObjectProperty, IsIndexable. La requête suivante indique
si on peut construire un index sur une vue :

SELECT ObjectProperty(object_id(‘Product_Totals’), ‘IsIndexable’)

Si la requête renvoie la valeur 1, cela indique que l’on a satisfait à  toutes
les contraintes, et on peut construire un index sur la vue.
Bien que ces contraintes puissent paraître sévères, les avantages des vues indexées
l’emportent sur les prérequis indispensables. Deux autres nouvelles fonctions
SQL Server 2000 (UDF, ou User-defined functions, et les index sur les colonnes
calculées) présentent de nombreuses contraintes similaires. Il faut en outre se
souvenir que ces restrictions s’appliquent aux définitions des vues et non aux
requêtes susceptibles d’utiliser les vues indexées.