Comment créer des vues matérialisées dans SQL Server?
Je vais concevoir un DW et j'ai entendu parler de vues matérialisées. En fait, je souhaite créer une vue qui devrait être mise à jour automatiquement lorsque les tables de base sont modifiées. Quelqu'un peut-il expliquer avec un exemple de requête ..
Elles s'appellent des vues indexées dans SQL Server - lisez ces livres blancs pour plus d'informations:
Fondamentalement, tout ce que vous devez faire est:
- créer une vue régulière
- créer un index clusterisé sur cette vue
et tu as fini!
La difficulté réside dans le fait que la vue doit satisfaire un grand 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 requise.
Ressources additionnelles:
Bien que du point de vue technique, les vues indexées sonnent comme une 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 les vues indexées là où j'en ai le plus besoin en raison d'un trop grand nombre de restrictions sur ce qui peut être indexé et ce qui ne 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 quelconque dans les tables de sous-sélection ou les tables dérivées (comme avec partition par clause), vous n’êtes pas plus chanceux.
Cela ne laisse que des scénarios très simples consistant à utiliser des vues indexées. À mon avis, quelque chose 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 dans lesquels des personnes ont utilisé des vues indexées à leur avantage et n'auraient pas pu s'en passer.
Vous aurez peut-être besoin d'un peu plus de connaissances 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 dans une forme de table. MVIEW est actualisé à l'aide d'une procédure en arrière-plan qui démarre à intervalles réguliers ou lorsque les données source sont modifiées. Oracle permet des actualisations complètes ou partielles.
Dans SQL Server, j’utiliserais ce qui suit pour créer un MVIEW de base afin de (compléter) l’actualisation régulière.
Tout d'abord, une vue. Cela devrait être facile pour la plupart des utilisateurs, car les vues sont assez courantes dans toutes les bases de données. Ensuite, une table. Cela devrait ê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 de l'expérimentation.
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 les requêtes ou autres vues qui le référencent pour qu'elles pointent vers la table de cache.
planifier tous les jours/tous les soirs/toutes les semaines/autres rafraîchissements, comme
begin transaction
truncate table cachetablename
insert into cachetablename select * from viewname
commit transaction
NB: cela occupera de l'espace, également dans vos journaux de tx. Recommandé pour les petits jeux de données lents à calculer. Peut-être que le refactor pour éliminer les colonnes "faciles mais grandes" en premier dans une vue extérieure.
Pour MS T-SQL Server, je suggère d’examiner la possibilité 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é. "Index ... Include ()" crée un stockage de données physique distinct, géré automatiquement par le système. Il ressemble conceptuellement à 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