6
votes

En utilisant des vues dans SQL

J'ai une vue créée à partir d'une table de base. Cette vue est essentiellement la copie exacte de la table sans aucune condition de filtrage et que toutes les colonnes et enregistrements de la table.

Y a-t-il un avantage à l'aide d'une vue (qui est une copie directe de la table) au lieu de la table directement dans ma demande ou des procédures stockées.


1 commentaires

Salut AVG, si l'une de ces réponses a été utile, veuillez envisager de marquer l'un d'entre eux comme accepté. Il est considéré comme de bonnes manières et encourage également les autres à répondre à vos questions à l'avenir. :)


7 Réponses :


0
votes

Dans ce cas, il n'y a pas de différence entre la vue et la table. La vue n'est pas une copie de la table, mais quelque chose comme une déclaration de sélection stockée.


0 commentaires

0
votes

Il peut y avoir de graves inconvénients à cette approche, d'un aspect performant.

http://www.sql-server-performance.com/tips /views_general_p1.aspx

Je suggérerais d'éviter l'utilisation de vues si possible.


1 commentaires

Comme indiqué dans les commentaires de l'article référencé, il y a plus de désinformation que de faits, et je suis d'accord avec l'affiche que l'article doit être supprimé. la spéculation et en disent ici ne substituent pas de preuves empiriques que l'article ne fournit pas.



0
votes

Nope.

À l'exception des vues indexées, les vues ne sont vraiment utiles que pour rendre le nettoyeur SQL à lire - exécuter une requête contenant une vue est essentiellement la même que d'exécuter une requête avec la définition de vue copiée et collée dans la requête.

Je découragerais l'utilisation de vues complexes de cette manière, bien que la requête soit plus propre, elle rend le processus de diagnostic davantage d'une douleur (comme vous devez rechercher toutes les vues pour comprendre ce que la requête originale est faire)


0 commentaires

3
votes

Mais vous devez être conscient que la façon dont les points de vue fonctionnent est un peu différent, car vous finissez par avoir des excédents sur le côté DB.

La manière dont une vue fonctionne, consiste à choisir *, puis filtrant elle-même pour les colonnes que vous y en ajoutez.

Je serais vraiment fatigué d'utiliser des points de vue pour cela, à moins d'avoir des problèmes de sécurité graves.

La voie à suivre est de créer une procédure stockée qui saisit les données directement à partir de la table. De cette façon, vous pouvez prendre le maximum d'index et tout cela.

acclamations


0 commentaires

0
votes

Il peut ne pas y avoir d'objet ou d'avantage immédiat, mais cela vous fournit un point d'abstraction qui peut fournir un avantage à la fois architectural ou de sécurité à un moment ultérieur.

La vue pourrait être essentiellement considérée comme un contrat de données, qui permet à l'avenir la structure sous-jacente à fléchir jusqu'à un point, sans le monde extérieur le réalisant.

du côté de la sécurité, à un point à l'avenir une clause où peut être inséré, ce qui commence à vous donner un filtrage / sécurité au niveau de la ligne, où l'accès direct à la table empêche tout déplacement futur.


0 commentaires

2
votes

Un avantage (ou un inconvénient, selon votre point de vue), c'est que les vues vous permettent de stocker la logique commerciale dans le serveur SQL, au lieu de votre code. Si vous devez modifier facilement l'entreprise sans recompiler votre code, la modification de la vue est un moyen rapide et facile de le faire.

Je préfère personnellement avoir la logique commerciale de l'application définie dans le code, cependant :)


0 commentaires

0
votes

Les vues peuvent être considérées comme une couche logique au sommet de la couche physique (table) dans votre cas au moment où la couche est si mince sa valeur peut être interrogée. Cependant, au fil du temps, tel peut être le cas. En utilisant une vue pour accéder à la table, coûte pratiquement rien, mais isole votre code des modifications possibles du modèle physique.


2 commentaires

Cette approche a des coûts en termes de performance et de maintenabilité. Les abstractions dans la couche ORM ou le PROP stockées doivent être suffisantes pour isoler le codeBase des modifications apportées au modèle physique.


@Ian: tout a un coût; La question est si elle dépassait l'avantage. Je n'ai lu aucune étude crédible identifiant les vues comme point de douleur de la performance. Bien sûr, l'utilisation inappropriée d'une API peut apporter un serveur à ses genoux - mais ce n'est guère la faute de l'API.