Comment créer des vues matérialisées dans SQL Server?

101

Je vais concevoir un DW et j'ai entendu parler de vues matérialisées. En fait, je veux créer une vue et elle devrait se mettre à jour automatiquement lorsque les tables de base sont modifiées. Quelqu'un peut-il expliquer avec un exemple de requête ...

sql-server database-design indexed-views Deepak
la source

Réponses:

144

Elles sont appelées vues indexées dans SQL Server - lisez ces livres blancs pour plus d'informations:

En gros, tout ce que vous avez à faire est:

  • créer une vue régulière
  • créer un index cluster sur cette vue

et tu as fini!

La partie délicate est la suivante: la vue doit satisfaire un certain nombre de contraintes et de limitations - celles-ci sont décrites dans le livre blanc. Si vous faites cela, c'est tout ce qu'il y a. La vue est mise à jour automatiquement, aucune maintenance n'est nécessaire.

Ressources supplémentaires:

marc_s
la source
Merci pour votre réponse. J'ai obtenu ce que je veux ... Je voudrais aussi en savoir plus sur les index. Je veux savoir s'il existe un moyen de générer un diagramme de schéma en étoile dans le serveur SQL lorsque toute la structure de la table est prête? Si oui, comment créer une table de faits pour cela?
Deepak
4
Les restrictions sur la mise d'un index cluster sur la vue sont étendues. Par exemple, la vue ne peut pas référencer d'autres vues et ne peut pas contenir de jointures externes. Ainsi, de nombreuses vues nécessitant de meilleures performances ne peuvent pas utiliser cette méthode. Encore une bonne réponse.
Jeff Wilson
2
Comme mentionné dans une question connexe, l'article du blog MSDN, blogs.msdn.microsoft.com/ssma/2011/06/20/… , met en évidence certaines des principales différences entre les vues matérialisées et les vues indexées. L'IMHO le plus problématique est de ne pas pouvoir spécifier des déclencheurs d'actualisation: les vues indexées sont mises à jour chaque fois que les tables de base sont mises à jour - ce qui compromet la plupart des avantages en termes de performances de l'utilisation d'une vue matérialisée. Les interdictions sur les jointures, les agrégats, les fonctions de fenêtrage et les sous-requêtes rendent les vues indexées presque inutiles à moins que les données ne changent souvent.
Suncat2000
43

Bien que purement du point de vue de l'ingénierie, les vues indexées semblent être quelque chose que tout le monde pourrait utiliser pour améliorer les performances, mais le scénario réel est très différent. Je n'ai pas réussi à utiliser des vues indexées là où j'en ai le plus besoin en raison de trop de restrictions sur ce qui peut être indexé et ce qui ne le peut pas.

Si vous avez des jointures externes dans les vues, elles ne peuvent pas être utilisées. De plus, les expressions de table courantes ne sont pas autorisées ... En fait, si vous avez un ordre dans les sous-sélections ou les tables dérivées (comme avec partition par clause), vous n'avez pas de chance aussi.

Cela ne laisse que des scénarios très simples à utiliser des vues indexées, quelque chose à mon avis peut être optimisé en créant de toute façon des index appropriés sur les tables sous-jacentes.

Je serai ravi d'entendre certains scénarios de la vie réelle où les gens ont effectivement utilisé des vues indexées à leur avantage et n'auraient pas pu se passer d'eux

Rajiv
la source
En fait, j'ai utilisé des vues indexées (une seule fois) pour partitionner un index de recherche en texte intégral. Les index FTS ne peuvent en effet pas être partitionnés, mais des index séparés peuvent être créés sur plusieurs vues de la même table. C'était une sorte de dernier recours, cependant.
areyesram
4
Vous devez vous rappeler d'ajouter un (NOEXPAND)indice aux requêtes qui utilisent les vues indexées. Et puis vous remarquez la différence. L'avantage d'utiliser les vues indexées par rapport à «indexer correctement les tables» est de limiter la sélection des enregistrements, sinon vous avez raison, ce serait pareil.
ajeh
Oui, la chose NOEXPAND ne peut pas être sous-estimée!
Simon_Weaver
18

Vous aurez peut-être besoin d'un peu plus d'informations sur ce qu'est réellement une vue matérialisée. Dans Oracle, il s'agit d'un objet composé d'un certain nombre d'éléments lorsque vous essayez de le construire ailleurs.

Un MVIEW est essentiellement un instantané de données provenant d'une autre source. Contrairement à une vue, les données ne sont pas trouvées lorsque vous interrogez la vue, elles sont stockées localement sous forme de table. Le MVIEW est actualisé à l'aide d'une procédure d'arrière-plan qui démarre à intervalles réguliers ou lorsque les données source changent. Oracle permet des actualisations complètes ou partielles.

Dans SQL Server, j'utiliserais ce qui suit pour créer un MVIEW de base pour (terminer) l'actualisation régulièrement.

Tout d'abord, une vue. Cela devrait être facile pour la plupart car les vues sont assez courantes dans n'importe quelle base de données Ensuite, une table. Cela doit être identique à la vue dans les colonnes et les données. Cela stockera un instantané des données de vue. Ensuite, une procédure qui tronque la table et la recharge en fonction des données actuelles de la vue. Enfin, un travail qui déclenche la procédure pour démarrer son travail.

Tout le reste est expérimentation.

Jason A.
la source
5
Vos commentaires sur SQL Server sont incorrects - les vues matérialisées sont des choses très différentes dans Oracle et SQL Server. Dans SQL Server, une vue avec un index cluster unique (aka une «vue matérialisée») ne peut pas et ne peut pas être mise à jour par l'utilisateur, ni stockée dans une table distincte créée par l'utilisateur - elle est toujours mise à jour par le moteur pendant les mises à jour et n'est jamais désynchronisé. Il n'y a pas besoin de travail pour stocker un instantané des données.
ErikE
10
Ce que le PO a demandé est facilement fourni par une vue indexée. C'est la chose la plus proche que SQL Server fournit nativement à une vue matérialisée Oracle. Cependant, si vous voulez / avez besoin de reproduire exactement le fonctionnement d'Oracle MVIEW, Jason a raison. L'approche de Jason aide également dans le même scénario que les MVIEW d'Oracle peuvent - par exemple, faire actualiser en dehors des heures un tableau de rapport où vous vous souciez plus de la charge de la base de données que de la mise à jour de la vue (par exemple, ne rapporter que les chiffres d'hier ...)
4

Lorsque la vue indexée n'est pas une option et que des mises à jour rapides ne sont pas nécessaires, vous pouvez créer une table de cache de piratage:

select * into cachetablename from myviewname
alter table cachetablename add primary key (columns)
-- OR alter table cachetablename add rid bigint identity primary key
create index...

puis sp_rename view / table ou modifiez toutes les requêtes ou autres vues qui la référencent pour qu'elles pointent vers la table de cache.

planifier quotidiennement / tous les soirs / hebdomadaires / quoi de neuf

begin transaction
truncate table cachetablename
insert into cachetablename select * from viewname
commit transaction

NB: cela va manger de l'espace, également dans vos logs tx. Idéal pour les petits ensembles de données lents à calculer. Peut-être refactoriser pour éliminer d'abord les colonnes «faciles mais grandes» dans une vue extérieure.

stox
la source
1

Pour MS T-SQL Server, je suggère de créer un index avec l'instruction "include". L'unicité n'est pas requise, pas plus que le tri physique des données associé à un index clusterisé. Le "Index ... Inclure ()" crée un stockage de données physique distinct automatiquement maintenu par le système. Il est conceptuellement très similaire à une vue matérialisée Oracle.

https://msdn.microsoft.com/en-us/library/ms190806.aspx

https://technet.microsoft.com/en-us/library/ms189607(v=sql.105).aspx

Scott Nightlinger
la source