Quels sont les inconvénients de l'utilisation de SqlServer Views ?

Question

Quels sont les inconvénients de l'utilisation de SqlServer Views ?

Je crée fréquemment des vues pour présenter mes données sous une forme dénormalisée.

Je trouve qu'il est beaucoup plus facile et donc plus rapide, moins sujet aux erreurs et mieux documenté, d'interroger l'une de ces jointures plutôt que de générer des requêtes complexes avec des jointures compliquées entre plusieurs tables. En particulier lorsque j'analyse les mêmes données (plusieurs champs identiques, des jointures entre les mêmes tables) sous différents angles.

Mais la création et l'utilisation de ces vues ont-elles un coût ?

Est-ce que je ralentis (ou accélère ?) le traitement des requêtes ?

Answer 1

Les points de vue présentent des avantages et des inconvénients.

Avantages :

1. Il s'agit de tables virtuelles qui ne sont pas stockées dans la base de données en tant qu'objet distinct. Tout ce qui est stocké est l'instruction SELECT.
2. Il peut être utilisé comme mesure de sécurité en limitant ce que l'utilisateur peut voir.
3. Il peut faciliter la lecture des requêtes complexes couramment utilisées en les encapsulant dans une vue. Il s'agit cependant d'une arme à double tranchant - voir inconvénients #3.

Inconvénients :

1. Elle ne dispose pas d'un plan d'exécution optimisé mis en cache et ne sera donc pas aussi rapide qu'une procédure stockée.
2. Comme il s'agit essentiellement d'une abstraction d'un SELECT, il est légèrement plus lent qu'un SELECT pur.
3. Elle peut masquer la complexité et entraîner des problèmes. (Gotcha : ORDER BY non respecté).

Je pense personnellement qu'il ne faut pas utiliser les vues, mais plutôt les procédures stockées, car elles offrent la sécurité et l'encapsulation des vues, tout en étant plus performantes.

Answer 2

L'un des inconvénients possibles de l'utilisation des vues est que vous abstrayez la complexité de la conception sous-jacente, ce qui peut conduire à des abus de la part des développeurs juniors et des créateurs de rapports.

Dans le cadre d'un projet particulièrement vaste et complexe, j'ai conçu un ensemble de vues qui devaient être utilisées principalement par les concepteurs de rapports pour alimenter les rapports Crystal. J'ai découvert des semaines plus tard que des développeurs juniors avaient commencé à utiliser ces vues pour récupérer des agrégats et joindre ces vues déjà volumineuses, simplement parce qu'elles existaient et étaient faciles à utiliser. (J'ai découvert cela après que les jeunes développeurs ont commencé à demander pourquoi des rapports apparemment simples prenaient de nombreuses minutes à s'exécuter.

Answer 3

L'efficacité d'une vue dépend en grande partie des tables sous-jacentes. La vue n'est en fait qu'un moyen organisé et cohérent d'examiner les résultats d'une requête. Si la requête utilisée pour former la vue est bonne et utilise des index appropriés sur les tables sous-jacentes, la vue ne devrait pas avoir d'impact négatif sur les performances.

Dans SQL Server, vous pouvez également créer des vues matérialisées ou indexées (depuis SQL Server 2000), ce qui augmente quelque peu la vitesse.

Answer 4

J'utilise aussi régulièrement des vues. Il convient toutefois de noter que l'utilisation d'un grand nombre de vues peut s'avérer difficile à maintenir si les tables sous-jacentes changent fréquemment (en particulier au cours du développement).

EDIT : Ceci dit, je trouve que la commodité et l'avantage de pouvoir simplifier et réutiliser des requêtes complexes l'emportent sur le problème de la maintenance, surtout si les vues sont utilisées de manière responsable.

Answer 5

Les vues peuvent nuire aux performances lorsqu'elles contiennent de la logique, des colonnes, des lignes ou des tables qui ne sont pas utilisées par la requête finale. Je ne peux pas vous dire combien de fois j'ai vu des choses comme :

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables)
WHERE Active = True 

(filtrant ainsi toutes les lignes de la table InactiveCustomer qui ont été incluses dans la vue), ou

SELECT (one column)
FROM (view that returns 50 columns)

(SQL doit récupérer un grand nombre de données qui sont ensuite rejetées lors d'une étape ultérieure. Il est possible que ces autres colonnes soient coûteuses à récupérer, comme par le biais d'une recherche de signets), ou

SELECT ...
FROM (view with complex filters)
WHERE (entirely different filters)

(il est probable que SQL aurait pu utiliser un index plus approprié si les tables avaient été interrogées directement), ou

SELECT (only fields from a single table)
FROM (view that contains crazy complex joins)

(beaucoup de surcharge CPU à travers la jointure, et des IO inutiles pour les lectures de table qui sont ensuite rejetées), ou mon préféré :

SELECT ...
FROM (Crazy UNION of 12 tables each containing a month of data)
WHERE OrderDate = @OrderDate

(Il lit 12 tables alors qu'il n'a besoin d'en lire qu'une).

En le plus Dans certains cas, SQL est suffisamment intelligent pour "voir à travers les couvertures" et proposer de toute façon un plan de requête efficace. Mais dans d'autres cas (en particulier les cas très complexes), il ne peut pas le faire. Dans chacune de ces situations, la solution a consisté à supprimer la vue et à interroger les tables sous-jacentes à la place.

A l'occasion de la au minimum (même si vous pensez que SQL serait suffisamment intelligent pour l'optimiser de toute façon), l'élimination de la vue peut parfois faciliter le débogage et l'optimisation de votre propre requête (ce qui doit être fait est un peu plus évident).