Pourquoi créez-vous une vue dans une base de données?

Quand et pourquoi quelqu'un décide-t-il qu'il doit créer une vue dans sa base de données? Pourquoi ne pas simplement exécuter une procédure stockée normale ou sélectionner?

Une vue offre plusieurs avantages.

1. Les vues peuvent masquer la complexité

Si vous avez une requête qui nécessite de joindre plusieurs tables, ou qui a une logique ou des calculs complexes, vous pouvez coder toute cette logique dans une vue, puis sélectionner dans la vue comme vous le feriez pour une table.

2. Les vues peuvent être utilisées comme mécanisme de sécurité

Une vue peut sélectionner certaines colonnes et / ou lignes d'une table (ou tables) et des autorisations définies sur la vue au lieu des tables sous-jacentes. Cela permet de faire apparaître uniquement les données qu'un utilisateur doit voir.

3. Les vues peuvent simplifier la prise en charge du code hérité

Si vous devez refactoriser une table qui casserait beaucoup de code, vous pouvez remplacer la table par une vue du même nom. La vue fournit exactement le même schéma que la table d'origine, tandis que le schéma réel a changé. Cela empêche le code hérité qui fait référence à la table de se casser, vous permettant de modifier le code hérité à votre guise.

Ce ne sont que quelques-uns des nombreux exemples de la façon dont les vues peuvent être utiles.

Entre autres, il peut être utilisé pour la sécurité. Si vous avez une table "client", vous voudrez peut-être donner à tous vos vendeurs l'accès aux champs nom, adresse, code postal, etc., mais pas credit_card_number. Vous pouvez créer une vue qui inclut uniquement les colonnes auxquelles ils doivent accéder, puis leur accorder l'accès à la vue.

Une vue est l'encapsulation d'une requête. Les requêtes qui sont transformées en vues ont tendance à être compliquées et, à ce titre, les enregistrer en tant que vue pour les réutiliser peut être avantageux.

Je crée généralement des vues pour dénormaliser et / ou agréger les données fréquemment utilisées à des fins de reporting.

ÉDITER

En guise d'élaboration, si je devais avoir une base de données dans laquelle certaines des entités étaient la personne, la société, le rôle, le type de propriétaire, la commande, les détails de la commande, l'adresse et le téléphone, où la table des personnes stockait à la fois les employés et les contacts et l'adresse et les tables téléphoniques stockaient des numéros de téléphone pour les personnes et les entreprises, et l'équipe de développement était chargée de générer des rapports (ou de rendre les données de rapport accessibles aux non-développeurs) telles que les ventes par employé, ou les ventes par client, ou les ventes par région, les ventes par mois , clients par état, etc. Je créerais un ensemble de vues qui dénormaliseraient les relations entre les entités de la base de données afin qu'une vue plus intégrée (sans jeu de mots) des entités du monde réel soit disponible. Certains des avantages pourraient inclure:

1. Réduire la redondance dans l'écriture de requêtes
2. Établir une norme pour les entités liées
3. Fournir des opportunités pour évaluer et maximiser les performances pour les calculs et jointures complexes (par exemple, indexation sur les vues Schemabound dans MSSQL)
4. Rendre les données plus accessibles et intuitives pour les membres de l'équipe et les non-développeurs.

Plusieurs raisons: si vous avez des jointures compliquées, il est parfois préférable d'avoir une vue afin que tout accès ait toujours les jointures correctes et que les développeurs n'aient pas à se souvenir de toutes les tables dont ils pourraient avoir besoin. En règle générale, cela peut être pour une application financière où il serait extrêmement important que tous les rapports financiers soient basés sur le même ensemble de données.

Si vous avez des utilisateurs que vous souhaitez limiter les enregistrements qu'ils peuvent voir, vous pouvez utiliser une vue, leur donner accès uniquement à la vue et non aux tables sous-jacentes, puis interroger la vue

Les rapports Crystal semblent préférer utiliser les vues aux procs stockés, donc les gens qui écrivent beaucoup de rapports ont tendance à utiliser beaucoup de vues

Les vues sont également très utiles lors de la refactorisation de bases de données. Vous pouvez souvent masquer la modification afin que l'ancien code ne la voit pas en créant une vue. Lisez les bases de données de refactorisation pour voir comment cela fonctionne car c'est un moyen très puissant de refactoriser.

Le principal avantage d'une vue sur une procédure stockée est que vous pouvez utiliser une vue comme vous utilisez une table. A savoir, une vue peut être référencée directement dans la FROMclause d'une requête. Par exemple, SELECT * FROM dbo.name_of_view.

À peu près de toutes les autres façons, les procédures stockées sont plus puissantes. Vous pouvez passer des paramètres, y compris les outparamètres qui vous permettent effectivement de revenir plusieurs valeurs à la fois, vous pouvez le faire SELECT, INSERT, UPDATEetDELETE les opérations, etc. , etc.

Si vous souhaitez que la vue puisse interroger à partir de la FROMclause, mais que vous souhaitez également pouvoir transmettre des paramètres, il existe un moyen de le faire également. Cela s'appelle une fonction table.

Voici un article assez utile sur le sujet:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDIT: Soit dit en passant, ce genre de question soulève la question, quel avantage a une vue sur une fonction table? Je n'ai pas vraiment de bonne réponse à cela, mais je noterai que la syntaxe T-SQL pour créer une vue est plus simple que pour une fonction table, et les utilisateurs de votre base de données peuvent être plus familiers avec les vues.

Il peut fonctionner comme un bon "intermédiaire" entre votre ORM et vos tables.

Exemple:

Nous avions une table Person dont nous devions changer la structure, donc la colonne SomeColumn allait être déplacée vers une autre table et aurait une relation un à plusieurs.

Cependant, la majorité du système, en ce qui concerne la personne, utilisait toujours la SomeColumn comme une seule chose, pas beaucoup de choses. Nous avons utilisé une vue pour rassembler toutes les SomeColumns et les mettre dans la vue, ce qui a bien fonctionné.

Cela a fonctionné car la couche de données avait changé, mais l'exigence métier n'avait pas fondamentalement changé, de sorte que les objets métier n'avaient pas besoin de changer. Si les objets métier devaient changer, je ne pense pas que cela aurait été une solution viable, mais les vues fonctionnent définitivement comme un bon point médian.

Pour se concentrer sur des vues de données spécifiques, les utilisateurs peuvent se concentrer sur des données spécifiques qui les intéressent et sur les tâches spécifiques dont ils sont responsables. Les données inutiles peuvent être ignorées. Cela augmente également la sécurité des données car les utilisateurs ne peuvent voir que les données définies dans la vue et non les données de la table sous-jacente. Pour plus d'informations sur l'utilisation des vues à des fins de sécurité, voir Utilisation des vues en tant que mécanismes de sécurité.

Pour simplifier la manipulation des données, les vues peuvent simplifier la façon dont les utilisateurs manipulent les données. Vous pouvez définir des jointures, des projections, des requêtes UNION et des requêtes SELECT fréquemment utilisées comme vues afin que les utilisateurs n'aient pas à spécifier toutes les conditions et qualifications chaque fois qu'une opération supplémentaire est effectuée sur ces données. Par exemple, une requête complexe utilisée à des fins de génération de rapports et qui effectue des sous-requêtes, des jointures externes et une agrégation pour récupérer des données à partir d'un groupe de tables peut être créée sous forme de vue. La vue simplifie l'accès aux données car la requête sous-jacente n'a pas besoin d'être écrite ou soumise à chaque génération du rapport; la vue est interrogée à la place. Pour plus d'informations sur la manipulation des données.

Vous pouvez également créer des fonctions définies par l'utilisateur en ligne qui fonctionnent logiquement comme des vues paramétrées ou des vues qui ont des paramètres dans les conditions de recherche de la clause WHERE. Pour plus d'informations, voir Fonctions définies par l'utilisateur en ligne.

Pour personnaliser les vues de données, autorisez différents utilisateurs à voir les données de différentes manières, même lorsqu'ils utilisent les mêmes données simultanément. Ceci est particulièrement avantageux lorsque des utilisateurs ayant de nombreux intérêts et niveaux de compétences différents partagent la même base de données. Par exemple, une vue peut être créée qui extrait uniquement les données des clients avec lesquels un gestionnaire de compte traite. La vue peut déterminer les données à récupérer en fonction de l'ID de connexion du gestionnaire de compte qui utilise la vue.

Pour exporter et importer des données, les vues peuvent être utilisées pour exporter des données vers d'autres applications. Par exemple, vous pouvez utiliser les magasins et les tables de vente de la base de données pubs pour analyser les données de vente à l'aide de Microsoft® Excel. Pour ce faire, vous pouvez créer une vue basée sur les magasins et les tables de vente. Vous pouvez ensuite utiliser l'utilitaire bcp pour exporter les données définies par la vue. Les données peuvent également être importées dans certaines vues à partir de fichiers de données à l'aide de l'utilitaire bcp ou de l'instruction BULK INSERT, à condition que des lignes puissent être insérées dans la vue à l'aide de l'instruction INSERT. Pour plus d'informations sur les restrictions de copie de données dans des vues, voir INSÉRER. Pour plus d'informations sur l'utilisation de l'utilitaire bcp et de l'instruction BULK INSERT pour copier des données vers et depuis une vue, voir Copie vers ou depuis une vue.

Pour combiner des données partitionnées L'opérateur d'ensemble Transact-SQL UNION peut être utilisé dans une vue pour combiner les résultats de deux requêtes ou plus à partir de tables distinctes en un seul ensemble de résultats. Cela apparaît à l'utilisateur comme une seule table appelée vue partitionnée. Par exemple, si une table contient des données de ventes pour Washington et une autre table contient des données de ventes pour la Californie, une vue peut être créée à partir de l'UNION de ces tables. La vue représente les données de vente pour les deux régions. Pour utiliser des vues partitionnées, vous créez plusieurs tables identiques, en spécifiant une contrainte pour déterminer la plage de données qui peut être ajoutée à chaque table. La vue est ensuite créée à l'aide de ces tables de base. Lorsque la vue est interrogée, SQL Server détermine automatiquement quelles tables sont affectées par la requête et fait uniquement référence à ces tables. Par exemple, si une requête spécifie que seules les données de vente pour l'État de Washington sont requises, SQL Server lit uniquement la table contenant les données de vente de Washington; aucune autre table n'est accessible.

Les vues partitionnées peuvent être basées sur des données provenant de plusieurs sources hétérogènes, telles que des serveurs distants, et pas seulement des tables de la même base de données. Par exemple, pour combiner les données de différents serveurs distants, chacun d'entre eux stockant des données pour une région différente de votre organisation, vous pouvez créer des requêtes distribuées qui récupèrent les données de chaque source de données, puis créer une vue basée sur ces requêtes distribuées. Toutes les requêtes lisent uniquement les données des tables sur les serveurs distants qui contiennent les données demandées par la requête; les autres serveurs référencés par les requêtes distribuées dans la vue ne sont pas accessibles.

Lorsque vous partitionnez des données sur plusieurs tables ou plusieurs serveurs, les requêtes n'accédant qu'à une fraction des données peuvent s'exécuter plus rapidement car il y a moins de données à analyser. Si les tables sont situées sur des serveurs différents ou sur un ordinateur avec plusieurs processeurs, chaque table impliquée dans la requête peut également être analysée en parallèle, améliorant ainsi les performances de la requête. De plus, les tâches de maintenance, telles que la reconstruction d'index ou la sauvegarde d'une table, peuvent s'exécuter plus rapidement. En utilisant une vue partitionnée, les données apparaissent toujours comme une seule table et peuvent être interrogées en tant que telles sans avoir à référencer manuellement la table sous-jacente correcte.

Les vues partitionnées peuvent être mises à jour si l'une de ces conditions est remplie: Un déclencheur INSTEAD OF est défini sur la vue avec une logique pour prendre en charge les instructions INSERT, UPDATE et DELETE.

La vue et les instructions INSERT, UPDATE et DELETE suivent les règles définies pour les vues partitionnées pouvant être mises à jour. Pour plus d'informations, voir Création d'une vue partitionnée.

https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

Voici deux raisons courantes:

Vous pouvez l'utiliser pour la sécurité. N'accordez aucune autorisation sur la table principale et créez des vues qui limitent l'accès aux colonnes ou aux lignes et accordez des autorisations aux utilisateurs pour voir la vue.

Vous pouvez l'utiliser pour plus de commodité. Réunissez des tableaux que vous utilisez tout le temps dans la vue. Cela peut rendre les requêtes cohérentes et plus faciles.

Il y a plus d'une raison à cela. Parfois, les requêtes de jointure courantes sont faciles, car on peut simplement interroger un nom de table au lieu de faire toutes les jointures.

Une autre raison est de limiter les données à différents utilisateurs. Ainsi, par exemple:

Tableau 1: colonnes - USER_ID; USERNAME; SSN

Les utilisateurs administrateurs peuvent avoir des privilèges sur la table réelle, mais les utilisateurs auxquels vous ne voulez pas avoir accès pour dire le SSN, vous créez une vue comme

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

Donnez-leur ensuite accès à la vue et non à la table.

Les vues peuvent être une aubaine lorsque vous effectuez des rapports sur des bases de données héritées. En particulier, vous pouvez utiliser des noms de table sensés au lieu de noms cryptiques à 5 lettres (où 2 d'entre eux sont un préfixe commun!), Ou des noms de colonne pleins d'abréviations qui, j'en suis sûr, avaient du sens à l'époque.

En général, je choisis des vues pour faciliter la vie, obtenir des détails étendus d'une entité stockée sur plusieurs tables (éliminer beaucoup de jointures dans le code pour améliorer la lisibilité) et parfois partager des données sur plusieurs bases de données ou même pour rendre les insertions plus faciles à lire.

Voici comment utiliser une vue avec des autorisations pour limiter les colonnes qu'un utilisateur peut mettre à jour dans le tableau.

/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview 
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;

/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1

Quand je veux voir un instantané d'une table (s), et / ou une vue (en lecture seule)

J'aime utiliser des vues sur des procédures stockées lorsque je n'exécute qu'une requête. Les vues peuvent également simplifier la sécurité, peuvent être utilisées pour faciliter les insertions / mises à jour de plusieurs tables et peuvent être utilisées pour prendre des instantanés / matérialiser des données (exécuter une requête de longue durée et conserver les résultats en cache).

J'ai utilisé des vues matérialisées pour exécuter des requêtes de long terme qui ne doivent pas être conservées avec précision en temps réel.

Les vues décomposent également la configuration et les tableaux très complexes en morceaux gérables facilement interrogables. Dans notre base de données, l'ensemble de notre système de gestion de table est divisé en vues à partir d'une grande table.

Cela ne répond pas exactement à votre question, mais j'ai pensé qu'il valait la peine de mentionner les vues matérialisées . Mon expérience est principalement avec Oracle mais soi-disant SQL-Server est assez similaire.

Nous avons utilisé quelque chose de similaire dans notre architecture pour résoudre les problèmes de performances XML. Nos systèmes sont conçus avec un grand nombre de données stockées au format XML sur une ligne et les applications peuvent avoir besoin d'interroger des valeurs particulières à l'intérieur. La gestion de nombreux XMLTypes et l'exécution de XPaths sur un grand nombre de lignes ont un impact important sur les performances.Nous utilisons donc une forme de vues matérialisées pour extraire les nœuds XML souhaités dans une table relationnelle chaque fois que la table de base change. Cela fournit effectivement un instantané physique de la requête à un moment donné par opposition aux vues standard qui exécuteraient leur requête à la demande.

Je vois davantage une procédure stockée comme une méthode que je peux appeler contre mes données, tandis que pour moi, une vue fournit un mécanisme pour créer une version synthétique des données de base par rapport auxquelles des requêtes ou des procédures stockées peuvent être créées. Je créerai une vue lorsque la simplification ou l'agrégation aura du sens. J'écrirai une procédure stockée lorsque je veux fournir un service très spécifique.

Une chose curieuse à propos des vues est qu'elles sont vues par Microsoft Access comme des tables: lorsque vous attachez un frontal Microsoft Access à une base de données SQL à l'aide d'ODBC, vous voyez les tables et les vues dans la liste des tables disponibles. Donc, si vous préparez des rapports compliqués dans MS Access, vous pouvez laisser le serveur SQL effectuer la jointure et l'interrogation, et simplifier considérablement votre vie. Idem pour préparer une requête dans MS Excel.

Je n'ai qu'une dizaine de vues dans mes bases de données de production. J'en utilise plusieurs pour les colonnes que j'utilise tout le temps. Un ensemble que j'utilise provient de 7 tables, certaines avec des jointures externes et plutôt que de réécrire que constamment je n'ai qu'à appeler cette vue dans une sélection et faire une ou 2 jointures. Pour moi, c'est juste un gain de temps.

Je crée xxx qui mappe toutes les relations entre une table principale (comme la table Products) et des tables de référence (comme ProductType ou ProductDescriptionByLanguage). Cela créera une vue qui me permettra de récupérer un produit et tous ses détails traduits de ses clés étrangères à sa description. Ensuite, je peux utiliser un ORM pour créer des objets pour construire facilement des grilles, des zones de liste déroulante, etc.

Considérez-le comme une refactorisation de votre schéma de base de données.

Je pense que le premier. Pour cacher la complexité de la requête. Son très approprié pour les vues. Comment quand nous normalisons les tables de base de données augmente. Maintenant pour récupérer des données est très difficile lorsque le nombre de tables augmente. Donc, la meilleure façon de gérer est de suivre les vues.

Nous créons une vue pour limiter ou restreindre l'accès à toutes les lignes / colonnes d'une table.Si le propriétaire souhaite que seules des lignes / colonnes spécifiques ou limitées doivent être partagées, il créera une vue avec ces colonnes.

Pour la sécurité: donne à chaque utilisateur l'autorisation d'accéder à la base de données uniquement via un petit ensemble de vues contenant les données spécifiques que l'utilisateur ou le groupe d'utilisateurs est autorisé à voir, ce qui restreint l'accès des utilisateurs à d'autres données.

Simplicité pour les requêtes et la structure : une vue peut tirer des données de plusieurs tables et présenter une seule table, simplifiant les informations et transformant les requêtes multi-tables en requêtes à table unique pour une vue et elle donne aux utilisateurs une vue spécifique de la structure de la base de données, présentant la base de données sous la forme d'un ensemble de tables virtuelles spécifiques à des utilisateurs ou groupes d'utilisateurs particuliers.

Pour créer une structure de base de données cohérente : les vues présentent une image cohérente et inchangée de la structure de la base de données, même si les tables source sous-jacentes sont modifiées.