Comment il est possible de créer des index clusterisés sur une vue dans SQL Server 2008. La vue n'est pas une table réelle, donc l'organisation physique des données regroupées n'a pas de sens l'index crée.Comment il est possible de créer un index cluster sur une vue
Où puis-je manquer le point?
Ceci est une explication quelque peu simplifiée. Il y a beaucoup de hoo-hah technique qui se passe sous le capot, mais on dirait que vous voulez une explication générale "wassup". Une vue est, pour l'essentiel, une requête pré-écrite et stockée; chaque fois que vous accédez à la vue, vous récupérez et branchez cette requête pré-écrite dans votre requête actuelle. (Ce que j'y pense est le moins souvent.)
Ainsi, ces vues "de base" lisent les données stockées dans les tables déjà présentes dans la base de données/sur le disque dur. Lorsque vous créez un index cluster sur une vue, ce que vous faites réellement est de faire une deuxième copie physique des données référencées par la vue. Par exemple, si vous avez la table A, créez view vA en tant que "select * from A", puis créez un index cluster sur cette vue, ce que vous obtenez avec est deux copies des données sur le disque dur. Cela peut être utile si le tableau A est très volumineux et si vous souhaitez accéder rapidement à un petit sous-ensemble de la table (par exemple, 2 ou 3 colonnes uniquement, ou si Status = 1 ou si vous souhaitez un accès rapide à la table). Le plaisir vient quand vous mettez à jour la table A (en fait, n'importe laquelle des tables référencées par la vue), car toute modification de la table "base" doit également être faite pour la table "vue". Ce n'est pas une bonne idée dans les systèmes OLTP fortement utilisés. Je pense que les «vues indexées» de SQL sont appelées «vues matérialisées» dans Oracle. Pour mon argent, Materialized View est un bien meilleur nom/description.
Cela ne fonctionne que dans les versions très coûteuses de SQL Server. –
C'est plus complexe que ça. Vous pouvez créer des vues indexées dans n'importe quelle version de SQL Server 2005 et versions ultérieures, mais en 2005, il existe des règles concernant l'édition, les indicateurs d'index et si l'optimiseur de requêtes envisagera de les utiliser ou non. En 2008, l'optimiseur de requêtes considérera toujours les vues indexées. –
Bien qu'une vue ne soit pas un objet réel, l'index cluster est.
Et les lignes retournées par la vue peuvent être triées et stockées. Toutefois, pour être indexable, la vue doit satisfaire à un certain nombre de conditions. Généralement, ils s'assurent que les résultats sont conservés et que les mises à jour de la table sous-jacente peuvent être facilement suivies dans une vue (de sorte que l'index n'aura pas à être reconstruit chaque fois que la table sous-jacente est mise à jour).
Par exemple, SUM(*) et COUNT_BIG(*) sont des fonctions distributives:
SUM(set1) + SUM(set2) = SUM(set1 + set2)
COUNT_BIG(set1) + COUNT_BIG(set2) = COUNT_BIG(set1 + set2)
, il est donc facile de recalculer les valeurs de SUM et COUNT_BIG lorsque la table est modifiée, en utilisant uniquement les lignes de vue et les valeurs des colonnes affectées .
Cependant, ce n'est pas le cas avec d'autres agrégats, ils ne sont donc pas autorisés dans une vue indexée.
Un index existe toujours sur le disque. Lorsque vous créez l'index, vous matérialisez les lignes de la vue sur le disque même si la vue elle-même n'est pas de "vraies" lignes.
MSDN White paper avec une explication
On dit que la vue indexée "matérialise" les données de vue - en ajoutant un index en cluster dans lequel le niveau de feuille sont les pages de données réelles, c'est exactement ce qui se passe. Et c'est exactement la raison pour laquelle une vue indexée est généralement beaucoup plus rapide qu'une vue "normale" –