Quels sont les inconvénients de L'utilisation des vues SqlServer?

Un inconvénient possible de l'utilisation des vues est que vous abstraites la complexité de la conception sous-jacente qui peut conduire à des abus par les développeurs juniors et les créateurs de rapports.

Pour 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 remplir crystal reports. J'ai découvert des semaines plus tard que les développeurs juniors avaient commencé à utiliser ces vues pour récupérer des agrégats et rejoindre ces vues déjà grandes simplement parce qu'elles étaient là et étaient facile à consommer. (Il y avait un élément important de la conception de L'EAV dans la base de données.) J'ai découvert à ce sujet après que les développeurs juniors aient commencé à demander pourquoi des rapports apparemment simples prenaient plusieurs minutes à exécuter.

L'efficacité d'une vue dépend en grande partie des tables sous-jacentes. La vue est vraiment un moyen organisé et cohérent de regarder les résultats de la 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.

J'utilise aussi des vues régulièrement. Une chose à noter, cependant, est que l'utilisation de beaucoup de vues pourrait être difficile à maintenir si vos tables sous-jacentes changent fréquemment (surtout pendant le développement).

EDIT: cela 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 maintenance, surtout si les vues sont utilisées de manière responsable.

Les vues peuvent nuire aux performances lorsque la vue contient de la logique, des colonnes, des lignes ou des tables qui ne sont pas utilisées par votre 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 incluses dans la vue à partir de la table InactiveCustomer), ou

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

(SQL doit récupérer beaucoup de données qui sont ensuite supprimées à une étape ultérieure. Il est possible que ces autres colonnes soient coûteuses à récupérer, comme à travers un signet recherche), 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 étaient interrogées directement), ou

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

(beaucoup de surcharge du processeur à travers la jointure, et des e / s 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

(Lit 12 tables quand il n'a vraiment besoin de lire que 1).

Dans la plupart des cas, SQL est assez intelligent pour" voir à travers les couvertures " et trouver un plan de requête efficace de toute façon. Mais dans d'autres dans chacune des situations ci-dessus, la réponse était de supprimer la vue et d'interroger les tables sous-jacentes à la place.

Au au moins (même si vous pensez que SQL serait assez 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 (un peu plus évident ce qui doit être fait).

Un inconvénient des vues que j'ai rencontrées est une plongée dans les performances lors de leur intégration dans des requêtes distribuées. Cet article SQLMag discute - et alors que j'utilise des données hautement artificielles dans la démo, j'ai rencontré ce problème maintes et maintes fois dans le "monde réel".

Respectez vos opinions, et ils vous traiteront bien.

Quelles sont les diverses Limitations des vues dans SQL Server?

Haut 11 Limitations de vues

• Vues ne prennent pas en charge COUNT (); cependant, il peut prendre en charge COUNT_BIG ()
• la clause ORDER BY ne fonctionne pas en vue
• les requêtes régulières ou les procédures stockées nous donnent de la flexibilité lorsque nous avons besoin d'une autre colonne; nous pouvons ajouter une colonne aux requêtes régulières tout de suite. Si nous voulons faire la même chose avec les vues, nous devrons les modifier premier
• Index créé sur la vue pas souvent utilisé
• Une fois la vue créée et si la table de base a une colonne ajoutée ou supprimée, elle n'est généralement pas reflétée dans la vue jusqu'à ce qu'elle soit actualisée
• L'opération UNION n'est pas autorisée dans la vue indexée
• nous ne pouvons pas créer un Index sur une vue imbriquée la situation signifie que nous ne pouvons pas créer d'index sur une vue construite à partir d'une autre vue.
• SOI JOINDRE Pas Autorisés en Vue Indexée
• jointure externe non autorisée dans indexé Vues
• requêtes inter-bases de données non autorisées dans la vue indexée

Source SQL MVP Pinal Dave

Http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

Quand j'ai commencé, je pensais toujours que les vues ajoutaient des frais généraux de performance, mais l'expérience peignait une histoire différente (le mécanisme de vue lui-même a des frais généraux négligeables).

Tout dépend de la requête sous-jacente. Consultez les vues indexées ici ou ici , en fin de compte, vous devez tester les performances des deux façons d'obtenir un profil de performance clair

Mon plus gros reproche est que ORDER BY ne fonctionne pas dans une vue. Alors qu'il fait sens, c'est un cas qui peut sauter et mordre si pas prévu. Pour cette raison, j'ai dû changer loin d'utiliser des vues pour SPROCS (qui ont plus que suffisamment de problèmes) dans quelques cas où je ne pouvais pas spécifier un ordre par plus tard. (Je souhaite qu'il y ait une construction avec "vue finale" - par exemple éventuellement inclure order by -- sémantique).

Http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/ (la Limitation # 1 concerne L'ordre Par: -)

Ce qui suit est un hack SQL qui permet à un order by d'être référencé dans une vue:

create view toto1 as 
select top 99.9999 percent F1
from Db1.dbo.T1 as a 
order by 1

, Mais ma préférence est d'utiliser Row_Number:

create view toto2 as 
select *,  ROW_NUMBER() over (order by [F1]) as RowN from ( 
select f1
from Db1.dbo.T1) as a