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

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

InformationsquelleAutor Deepak | 2010-10-21
  1. 123

    Ils sont appelés vues indexées dans SQL Server lire ces livres blancs pour plus d'arrière-plan:

    Fondamentalement, tout ce que vous devez faire est de:

    • créer un affichage normal
    • créer un index cluster sur ce point de vue

    et vous avez terminé!

    La partie la plus délicate est: le point de vue doit répondre à un certain nombre de contraintes et limites - celles qui sont énoncées dans le livre blanc. Si vous le faites, c'est tout. La vue est mise à jour automatiquement, aucune maintenance n'est nécessaire.

    Ressources supplémentaires:

    • Merci pour votre réponse. J'ai obtenu ce que je veux.. je voudrais savoir à propos des index ainsi. Je veux savoir est-il un moyen de générer du schéma en étoile schéma dans SQL server lorsque j'ai toute la structure de la table prêt ? Si Oui comment puis-je créer des tables de fait pour qui ?
    • Les restrictions sur la mise un index cluster sur la vue sont nombreuses. Par exemple, la vue ne peut pas référence à d'autres points de vue et ne peut pas contenir les jointures externes. Ainsi, de nombreux points de vue qui ont besoin d'améliorer les performances peuvent pas utiliser cette méthode. Encore une bonne réponse.
    • Comme mentionné dans une question connexe, la MSDN article de blog, blogs.msdn.microsoft.com/ssma/2011/06/20/..., met en évidence les principales différences entre les vues matérialisées et les vues indexées. Le plus problématique à mon humble avis n'est pas en mesure de préciser l'actualisation des déclencheurs: les vues indexées sont mis à jour chaque fois que les tables de base sont mis à jour à saper la plupart des avantages de performance de l'aide d'une vue matérialisée. Les interdictions sur les jointures, les agrégats, les fonctions de fenêtrage, et les sous-requêtes rend les vues indexées presque inutile, à moins que des données ne change pas souvent.
    InformationsquelleAutor marc_s
  2. 36

    Bien que purement du point de vue technique, les vues indexées sonne comme quelque chose que tout le monde pourrait utiliser pour améliorer les performances, mais le scénario de la vie réelle est très différente. J'ai succombé en ses moyens est l'utilisation de vues indexées où j'ai le plus besoin en raison d'un trop grand nombre de restrictions sur ce qui peut être indexé et ce qui ne l'est pas.

    Si vous avez des jointures externes dans les points de vue, ils ne peuvent pas être utilisés. Aussi, les expressions de table communes ne sont pas autorisées... En fait, si vous avez n'importe quel ordre dans les sous-sélections ou les tables dérivées (comme avec la partition par la clause de), vous êtes hors de la chance aussi.

    Qui ne laisse que très simple scénarios utilisant les vues indexées, quelque chose à mon avis peut être optimisé par la création d'index appropriés sur les tables sous-jacentes de toute façon.

    Je serai ravi d'entendre certains des scénarios de vie réelle, où les gens ont effectivement utilisé les vues indexées à leur avantage et ne pouvait pas faire sans eux

    • En fait, j'ai utilisé des Vues Indexées (juste une fois) pour la partition d'un Texte Complet de l'index de Recherche. FTS indices, en effet, ne peut pas être partitionné, mais les différents index peut être créé sur plusieurs vues de la même table. C'était une sorte de dernier recours, si.
    • Vous devez n'oubliez pas d'ajouter (NOEXPAND) astuce pour les requêtes qui utilisent les vues indexées. Et puis vous verrez la différence. L'avantage d'utiliser les vues indexées vs "correctement indexation des tables" est dans la limitation de la sélection de l'enregistrement, sinon vous avez raison, ce serait le même.
    InformationsquelleAutor Rajiv
  3. 17

    Vous pourriez avoir besoin d'un peu plus de fond sur ce qu'est une Vue Matérialisée est en réalité. Dans Oracle ceux-ci sont un objet qui se compose d'un certain nombre d'éléments lorsque vous essayez de construire ailleurs.

    Un MVIEW est essentiellement un aperçu des données provenant d'une autre source. Contrairement à afficher les données ne sont pas disponibles lorsque vous interrogez la vue, il est stocké localement dans une forme de tableau. Le MVIEW est actualisée à l'aide d'un arrière-plan de la procédure qui débute à intervalles réguliers ou lorsque la modification des données source. Oracle permet, intégral ou partiel, rafraîchit.

    Dans SQL Server, je voudrais utiliser ce qui suit pour créer une base de MVIEW à (complet) actualiser régulièrement.

    Tout d'abord, d'un point de vue. Ce devrait être facile pour la plupart des puisque les avis sont assez fréquents dans une base de données
    Ensuite, une table. Cela devrait être identique à la vue dans les colonnes et les données. Cela permettra de stocker un instantané de la vue de données.
    Ensuite, une procédure qui tronque la table, et la recharge, basée sur les données de la vue.
    Enfin, un travail qui déclenche la procédure pour démarrer le travail.

    Tout le reste est de l'expérimentation.

    • Vos commentaires sur SQL Server sont incorrectes--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 sur elle (un.k.un. une "vue matérialisée") n'est pas et ne peut pas être mis à jour par l'utilisateur, ni est-il stocké dans un autre créé par l'utilisateur table--il est toujours mis à jour par le moteur lors des mises à jour, et n'est jamais hors de synchronisation. Il n'est pas besoin de travail pour stocker un instantané des données.
    • Ce que l'OP a demandé est facilement fournis par une vue indexée. C'est la chose la plus proche de SQL Server en mode natif fournit un Oracle de la vue matérialisée. Cependant, si vous voulez/besoin de reproduire la manière d'un Oracle MVIEW œuvres, Jason est de droit. Jason approche permet également dans le même scénario Oracle MVIEWs pouvez par exemple faire en dehors des heures d'actualisation d'un tableau où vous souciez plus de la charge de base de données de façon à jour la vue est (par exemple, les rapports uniquement sur hier les chiffres de l'...)
    InformationsquelleAutor Jason A.
  4. 2

    Lors de la vue indexée n'est pas une option, et des mises à jour rapides ne sont pas nécessaires, vous pouvez créer un hack cache de tableau:

    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/table de vue ou de modifier toutes les requêtes ou d'autres points de vue qui font référence à la table du cache.

    calendrier tous les jours/tous les soirs/semaine/autres joyeusetés actualiser comme

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

    NB: il va manger de l'espace, aussi dans votre tx journaux. Meilleur utilisé pour de petits ensembles de données qui sont lentes à calculer. Peut-être refactoriser pour éliminer les "facile, mais de grandes colonnes d'abord en vue extérieure.

    InformationsquelleAutor stox
  5. 1

    Pour MS T-SQL Server, je suggère à la recherche dans la création d'un index avec "include" de la déclaration. La singularité n'est pas nécessaire, ni le physique de tri de données associé à un index cluster. L ' "Indice ... Include ()" crée un autre physique de stockage de données gérée automatiquement par le système. Il est conceptuellement très similaire à un Oracle de la Vue Matérialisée.

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

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

    InformationsquelleAutor Scott Nightlinger