serveur SQL indexé en cluster sur une vue

Question

J'essaie de créer une vue à partir d'une requête de sélection assez complexe et elle ne me laissera pas mettre un index clusterisé dessus car je dois utiliser des sous-requêtes et des fonctions d'agrégat.

Je dois obtenir un index clusterisé, sinon les requêtes utilisant la vue prendront une éternité. Apparemment, le serveur SQL ne stockera le jeu de résultats que si vous remplissez une quantité stupide de critères.

Les tables de base de la vue sont en lecture seule et ne sont mises à jour que par une importation en masse une fois par jour. Je ne vois pas pourquoi les résultats ne peuvent pas être mis en cache.

Est-ce que quelqu'un connaît un moyen quelconque de faire en sorte que SQL Server mette en cache les résultats d'une vue afin de pouvoir les interroger ultérieurement ?? Je ne veux pas vraiment créer une autre table, car cela ferait boule de neige en un tas de changements un peu partout.

Merci d'avance.

Answer 1

Je pense que la réponse que vous recherchez est la suivante: Ne pas utiliser une vue pour faire cela. Utilisez une table avec les champs correspondant aux champs retournés de la requête SQL. Automatiser la requête pour remplir cette table

Answer 2

La réponse courte est qu’il est impossible de créer un index clusterisé, pour les raisons que vous avez mentionnées.

Lorsque vous demandez un moyen de mettre en cache les résultats de la requête complexe, le seul autre objet fourni par SQL Server (et qui résoudra votre problème) est un tableau.

Si l’automatisation pose un problème, envisagez de créer la vue, mais utilisez-la uniquement comme moyen d’insertion dans une table. Vous pouvez ainsi tronquer / insérer dans la table (en sélectionnant dans la vue) immédiatement après la fin. insertion en vrac.

Si vous utilisez SSIS (SQL Server Integration Services), il s'agit d'une opération relativement simple à ajouter.

Answer 3

Autant que je sache, lors de la compilation des plans d'exécution, SQL Server copie et colle la définition de la vue dans la requête lors de la compilation. Tant que vous pouvez ajouter des index aux tables sous-jacentes, vous devez pouvoir obtenir de bonnes performances de la requête.

Answer 4

Ce que vous construisez ressemble à un entrepôt de données. Par conséquent, votre meilleure option est de manipuler les données une fois qu'elles sont dans le système. Vous pouvez créer de nouvelles tables dénormalisées (ou modifier quoi que ce soit d'autre) et les indexer pour permettre une interrogation rapide.

Vous pouvez ensuite créer des vues au-dessus de ces tables si vous en avez besoin.

Answer 5

lorsque vous utilisez des agrégats dans une vue indexée, vous devez utiliser COUNT_BIG () au lieu de COUNT (), sinon la vue ne sera pas créée

De même, si vous n'êtes pas sous Enterprise Edition, vous devez fournir l'indicateur NOEXPAND, sinon l'optimiseur n'utilisera pas la vue

.

SELECT *
FROM YourView WITH(NOEXPAND)
WHERE ....

Peut-être que vous n'avez pas besoin d'une vue mais que vous n'avez pas les index corrects sur les tables, pouvez-vous poster le DDL des tables (y compris les index et les contraintes)

Answer 6

J'ai eu le même problème et j'ai fini par placer les sous-requêtes dans des vues d'index en cluster elles-mêmes.