L'indexation de vues avec une expression de table commune

1. Vous ne pouvez pas l'indice d'un point de vue avec une expression de table commune. Même si la vue peut ont SCHEMABINDING. Pensez-y de cette façon. Afin d'index d'un point de vue, il doit satisfaire à deux conditions (et beaucoup d'autres): (a) qu'il a été créé WITH SCHEMABINDING et (b) qu'il ne contient pas de CTE. Afin de schemabind vue, il ne pas besoin à satisfaire à la condition qu'il ne contienne pas une expression de table commune.

2. Je ne suis pas convaincu qu'il y a un scénario dans lequel un point de vue a un CTE et bénéficieront de cours d'indexation. C'est un périphérique à votre question, mais mon instinct me dit que vous essayez d'indice de ce point de vue, par magie, le rendre plus rapide. Une vue indexée n'est pas nécessairement plus vite qu'une requête sur les tables de base - il y a des restrictions pour une raison, et il y a seulement particulier les cas d'utilisation où ils font sens. Veuillez faire attention à ne pas seulement aveuglément tous les index de votre point de vue comme une magie "aller plus vite" bouton. Rappelez-vous aussi qu'une vue indexée nécessite un entretien. Donc, il va augmenter le coût de toutes les opérations DML dans votre charge de travail qui influent sur la table de base(s).

3. Schemabinding est pas juste pour l'indexation des points de vue. Il peut également être utilisé
   sur des choses comme les fonctions définies par l'utilisateur pour l'aider à persuader le déterminisme, peut être utilisé sur
   les vues et les fonctions à empêcher les modifications sur le schéma sous-jacent, et
   dans certains cas, il peut améliorer les performances (par exemple, lorsqu'un fichier UDF est
   pas lié à un schéma, l'optimiseur peut-être pour créer une table bobine de
   manipuler tous les sous-jacents des modifications DDL). Merci donc de ne pas penser que c'est
   bizarre que vous pouvez schéma lier un point de vue, mais vous ne pouvez pas indexer.
   L'indexation d'une vue exige, mais la relation n'est pas réciproque.

Pour votre scénario spécifique, je vous recommande ceci:

CREATE VIEW dbo.PatClassCounts
WITH SCHEMABINDING
AS
  SELECT pat_id, drug_class, 
      COUNT_BIG(*) AS counts
    FROM dbo.rx
    GROUP BY pat_id, drug_class;
GO
CREATE UNIQUE CLUSTERED INDEX ON dbo.PatClassCounts(pat_id, drug_class);
GO
CREATE VIEW dbo.ClaimSums
WITH SCHEMABINDING
AS
  SELECT pat_id, 
    SUM(c.std_cost) AS [Healthcare Costs], 
    COUNT_BIG(*) AS counts
  FROM dbo.claims
  GROUP BY pat_id;
GO
CREATE UNIQUE CLUSTERED INDEX ON dbo.ClaimSums(pat_id);
GO

Maintenant, vous pouvez créer une vue indexée juste fait une jointure entre ces deux vues indexées, et il va utiliser les index (vous pourriez avoir à utiliser NOEXPAND sur une édition inférieure, pas sûr):

CREATE VIEW dbo.OriginalViewName
WITH SCHEMABINDING
AS
    SELECT p.pat_id, p.drug_class, p.counts, c.[Healthcare Costs]
      FROM dbo.PatClassCounts AS p
      INNER JOIN dbo.ClaimSums AS c
      ON p.pat_id = c.pat_id;
GO

Maintenant, tout cela suppose qu'il vaut la peine de pré-regrouper cette information si vous exécutez cette requête rarement, mais les données sont modifiées beaucoup, il peut être préférable de ne PAS créer des vues indexées.

Également de noter que la SUM(std_cost) de la ClaimSums vue sera la même pour tous les pat_id + drug_class combinaison, puisque c'est seulement agrégées à pat_id. Je pense qu'il y a peut-être un drug_class dans le claims tableau qui devraient faire partie des critères de jointure trop, mais je ne suis pas sûr. Si c'est le cas, je pense que cela pourrait être réduites à une seule vue indexée.