CREATE VIEW (Transact-SQL)

S’applique à :SQL ServerBase de données Azure SQLAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Point de terminaison d'analyse SQL dans Microsoft FabricEntrepôt dans Microsoft FabricBase de données SQL dans Microsoft Fabric

Crée une table virtuelle dont le contenu (colonnes et lignes) est défini par une requête. Utilisez cette instruction pour créer une vue des données dans une ou plusieurs tables de la base de données. Par exemple, une vue peut être utilisée aux fins suivantes :

• pour affiner, simplifier et personnaliser la perception de la base de données par chaque utilisateur ;

• comme mécanisme de sécurité en permettant aux utilisateurs d'accéder aux données par le biais de la vue, sans leur accorder d'autorisations qui leur permettraient d'accéder directement aux tables de base sous-jacentes de la vue ;

• pour fournir une interface à compatibilité descendante pour émuler une table dont le schéma a été modifié.

Conventions de la syntaxe Transact-SQL

Syntaxe

Syntaxe pour SQL Server et Azure SQL Database.

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [ (column [ ,...n ] ) ]
[ WITH <view_attribute> [ ,...n ] ]
AS select_statement
[ WITH CHECK OPTION ]
[ ; ]  

<view_attribute> ::=
{  
    [ ENCRYPTION ]  
    [ SCHEMABINDING ]  
    [ VIEW_METADATA ]
}

Syntaxe pour Azure Synapse Analytics et Parallel Data Warehouse.

CREATE VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
AS <select_statement>   
[;]  

<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Syntaxe pour le point de terminaison d’analytique Microsoft Fabric Data Warehouse et SQL.

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
[ WITH <view_attribute> [ ,...n ] ] AS <select_statement>   
[;]

<view_attribute> ::=
{  
    [ SCHEMABINDING ]  
}

<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Les arguments

OU ALTER

S’applique à : Azure SQL Database et SQL Server (depuis SQL Server 2016 (13.x) SP1).

Modifie, de manière conditionnelle, la vue uniquement si elle existe déjà.

schema_name
Nom du schéma auquel appartient la vue.

view_name
Nom de la vue. Les noms des vues doivent se conformer aux règles applicables aux identificateurs. Vous n'êtes pas tenu de spécifier le nom du propriétaire de la vue.

colonne
Nom à utiliser pour une colonne dans une vue. Un nom de colonne est obligatoire uniquement lorsqu’une colonne est dérivée d’une expression arithmétique, d’une fonction ou d’une constante ; lorsque deux colonnes ou plus peuvent avoir le même nom, généralement en raison d’une jointure ; ou lorsqu’une colonne d’une vue est spécifiée un nom différent de celui de la colonne à partir de laquelle elle est dérivée. Les noms de colonnes peuvent également être attribués dans l’instruction SELECT .

Si la colonne n’est pas spécifiée, les colonnes d’affichage obtiennent les mêmes noms que les colonnes de l’instruction SELECT .

Notes

Dans les colonnes de la vue, les autorisations d’un nom de colonne s’appliquent sur une CREATE VIEW ou ALTER VIEW une instruction, quelle que soit la source des données sous-jacentes. Par exemple, si des autorisations sont accordées sur la SalesOrderID colonne dans une instruction CREATE VIEW, une ALTER VIEW instruction peut nommer la SalesOrderID colonne avec un nom de colonne différent, par OrderRefexemple, et disposer toujours des autorisations associées à la vue à l’aide SalesOrderIDde .

COMME

Actions que la vue doit réaliser.

select_statement

Instruction SELECT qui définit la vue. Elle peut utiliser plusieurs tables et d'autres vues. Les autorisations appropriées sont requises pour sélectionner les objets référencés dans la SELECT clause de la vue créée.

Une vue n’a pas besoin d’être un sous-ensemble des lignes et colonnes d’une table particulière. Une vue peut être créée qui utilise plusieurs tables ou autres vues avec une SELECT clause de toute complexité.

Dans une définition d’affichage indexée, l’instruction SELECT doit être une instruction de table unique ou un multitable JOIN avec agrégation facultative.

Les SELECT clauses d’une définition de vue ne peuvent pas inclure :

• Une ORDER BY clause, sauf s’il existe également une TOP clause dans la liste de sélection de l’instruction SELECT

  Important

  La ORDER BY clause est utilisée uniquement pour déterminer les lignes retournées par la ou TOP la OFFSET clause dans la définition d’affichage. La ORDER BY clause ne garantit pas les résultats ordonnés lorsque la vue est interrogée, sauf si ORDER BY elle est également spécifiée dans la requête elle-même.

• Mot clé INTO

• Clause OPTION

• une référence à une table temporaire ou à une variable de type table.

Étant donné que select_statement utilise l’instruction SELECT , il est valide d’utiliser des indicateurs de jointure et des indicateurs de table comme spécifié dans la FROM clause. Pour plus d’informations, consultez FROM (Transact-SQL) et SELECT (Transact-SQL).

Les fonctions et plusieurs SELECT instructions séparées par UNION ou UNION ALL peuvent être utilisées dans select_statement.

WITH CHECK OPTION.

Oblige toutes les instructions de modification de données exécutées sur la vue à respecter les critères définis dans select_statement. Lorsqu’une ligne est modifiée par le biais d’une vue, les WITH CHECK OPTION données restent visibles après la validation de la modification.

Notes

La CHECK OPTION seule s’applique aux mises à jour effectuées par le biais de la vue. Elle ne s’applique pas aux mises à jour effectuées directement dans les tables sous-jacentes d’une vue.

CHIFFREMENT

S’applique à : SQL Server 2008 (10.0.x) et versions ultérieures, et Azure SQL Database.

Chiffre les entrées dans sys.syscomments qui contiennent le texte de l’instruction CREATE VIEW . L’utilisation WITH ENCRYPTION empêche la publication de la vue dans le cadre de la réplication SQL Server.

SCHEMABINDING

Lie la vue au schéma des tables sous-jacentes ou des autres tables. Quand SCHEMABINDING elle est spécifiée, la table de base ou les tables ne peuvent pas être modifiées d’une manière qui affecterait la définition de la vue. Cette dernière doit d'ailleurs être modifiée ou supprimée au préalable pour supprimer les dépendances par rapport à la table qui doit être modifiée. Lorsque vous utilisez SCHEMABINDING, le select_statement doit inclure les noms en deux parties (schéma).objet) des tables, des vues ou des fonctions définies par l’utilisateur qui sont référencées. Tous ces objets référencés doivent se trouver dans la même base de données.

Les vues ou les tables impliquées dans une vue créée avec la clause SCHEMABINDING ne peuvent pas être supprimées, sauf si cette vue perd, à la suite de sa suppression ou de sa modification, la liaison au schéma. Dans le cas contraire, le Moteur de base de données génère une erreur. En outre, l’exécution d’instructions ALTER TABLE sur des tables qui participent à des vues qui ont une liaison de schéma échoue lorsque ces instructions affectent la définition de la vue.

VIEW_METADATA

Indique que l'instance de SQL Server retourne aux interfaces de programmation d'applications (API) DB-Library, ODBC et OLE DB les informations de métadonnées sur la vue, plutôt que sur la ou les tables de base, lorsque des métadonnées en mode lecture sont sollicitées pour une requête qui fait référence à la vue. Les métadonnées en mode Parcourir correspondent à des métadonnées supplémentaires que l'instance de SQL Server retourne à ces API clientes. Ces métadonnées permettent aux API clientes d'implémenter des curseurs clients pouvant être mis à jour. Les métadonnées en mode Parcourir comprennent des informations sur la table de base à laquelle appartiennent les colonnes du jeu de résultats.

Pour les vues créées avec VIEW_METADATA, les métadonnées en mode de navigation retournent le nom de la vue et non les noms de table de base lorsqu’elles décrivent les colonnes de la vue dans le jeu de résultats.

Lorsqu’une vue est créée à l’aide WITH VIEW_METADATAde , toutes ses colonnes, à l’exception d’une colonne d’horodatage , sont modifiables si l’affichage a INSTEAD OF INSERT ou INSTEAD OF UPDATE se déclenche. Pour plus d'informations sur les vues pouvant être mises à jour, consultez les Notes ci-dessous.

Notes

Vous ne pouvez créer des vues que dans la base de données actuelle. Il CREATE VIEW doit s’agir de la première instruction d’un lot de requêtes. Une vue ne peut faire référence qu'à un maximum de 1 024 colonnes.

Lorsque vous effectuez une requête par l'intermédiaire d'une vue, le Moteur de base de données vérifie que tous les objets de base de données référencés dans l'instruction existent, qu'ils sont bien valides dans le contexte de l'instruction et que les instructions de modification de données ne violent pas les règles d'intégrité des données. Si une vérification échoue, le système retourne un message d'erreur. Si la vérification réussit, l'action est transformée en une action applicable dans la ou les tables sous-jacentes.

Si une vue dépend d'une table ou d'une vue qui a été supprimée, le Moteur de base de données envoie un message d'erreur lors de toute tentative d'utilisation de la vue. Si une table ou une vue est créée pour remplacer celle qui a été supprimée et que la structure de la table n'est pas modifiée par rapport à la table de base précédente, la vue est de nouveau utilisable. Si la structure de la nouvelle table ou vue change, la vue doit être supprimée puis recréée.

Si une vue n’est pas créée avec la SCHEMABINDING clause, exécutez sp_refreshview lorsque des modifications sont apportées aux objets sous-jacents à la vue qui affectent la définition de la vue. Autrement, la vue risque de produire des résultats imprévisibles en cas d'interrogation.

Quand une vue est créée, les informations la concernant sont stockées dans les vues de catalogue suivantes : sys.views, sys.columns et sys.sql_expression_dependencies. Le texte de l’instruction CREATE VIEW est stocké dans l’affichage catalogue sys.sql_modules .

Une requête qui utilise un index sur une vue définie avec des expressions numériques ou flottantes peut avoir un résultat différent d’une requête similaire qui n’utilise pas l’index sur la vue. Cette différence peut être due à l’arrondi des erreurs pendant INSERT, DELETEou UPDATE des actions sur des tables sous-jacentes.

Le moteur de base de données enregistre les paramètres et SET QUOTED_IDENTIFIERSET ANSI_NULLS quand une vue est créée. Ces paramètres d'origine servent à analyser la vue lorsque celle-ci est utilisée. Par conséquent, tous les paramètres de session client pour SET QUOTED_IDENTIFIER et SET ANSI_NULLS n’affectent pas la définition d’affichage lorsque l’affichage est accessible.

Dans Azure Synapse Analytics, les vues ne prennent pas en charge la liaison de schéma. Par conséquent, si des modifications sont apportées aux objets sous-jacents, vous devez supprimer et recréer la vue pour actualiser les métadonnées sous-jacentes. Pour plus d’informations, consultez Vues T-SQL avec un pool SQL dédié et un pool SQL serverless dans Azure Synapse Analytics.

Dans Azure Synapse Analytics, les vues pouvant être mises à jour, les déclencheurs DML (de type AFTER ou INSTEAD OF) et les vues partitionnée ne sont pas pris en charge. Pour plus d’informations, consultez Vues T-SQL avec un pool SQL dédié et un pool SQL serverless dans Azure Synapse Analytics.

Dans Azure Synapse Analytics, les vues partitionnée ne sont pas prises en charge. Pour plus d’informations, consultez Vues T-SQL avec un pool SQL dédié et un pool SQL serverless dans Azure Synapse Analytics.

Dans la base de données Fabric SQL, les vues peuvent être créées, mais elles ne sont pas mises en miroir dans Fabric OneLake. Pour plus d’informations, consultez Limitations de la mise en miroir de bases de données Sql Fabric.

Vues pouvant être mises à jour

Pour modifier les données d'une table sous-jacente, vous pouvez utiliser une vue sous réserve que les conditions suivantes soient vraies :

• Toutes les modifications, y compris UPDATE, INSERTet DELETE les instructions, doivent référencer des colonnes à partir d’une seule table de base.

• Les colonnes étant modifiées dans la vue doivent faire référence directement aux données sous-jacentes se trouvant dans les colonnes des tables. Les colonnes ne peuvent être dérivées de quelque autre façon, telle que par :

  • Fonction d’agrégation : AVG, , COUNT, SUMMINMAXGROUPINGSTDEVSTDEVPVAR.VARP

  • un calcul, car la colonne ne peut être calculée à partir d'une expression utilisant d'autres colonnes ; de même, les colonnes formées par le biais des opérateurs UNION, UNION ALL, CROSSJOIN, EXCEPT et INTERSECT équivalent à une somme de calculs et ne peuvent donc pas être mises à jour.

• Les colonnes en cours de modification ne sont pas affectées par GROUP BY, HAVINGou DISTINCT par des clauses.

• TOP n’est pas utilisé n’importe où dans la select_statement de la vue avec la WITH CHECK OPTION clause.

Les restrictions précédentes s'appliquent à toutes les sous-requêtes de la clause FROM participant à créer la vue, tout comme elles s'appliquent aussi à la vue même. De façon générale, le Moteur de base de données doit pouvoir suivre les modifications de façon claire, à partir de la définition de la vue vers une table de base. Pour plus d’informations, consultez Modifier les données par l’intermédiaire d’une vue.

Si les restrictions précédentes vous empêchent de modifier des données directement à travers une vue, voici quelques options à considérer pour vous aider :

• Déclencheurs INSTEAD OF

  INSTEAD OF les déclencheurs peuvent être créés sur une vue pour rendre un affichage pouvant être mis à jour. Le INSTEAD OF déclencheur est exécuté au lieu de l’instruction de modification de données sur laquelle le déclencheur est défini. Ce déclencheur permet à l'utilisateur de spécifier l'ensemble d'actions à exécuter pour traiter l'instruction de modification de données. Par conséquent, si un INSTEAD OF déclencheur existe pour une vue sur une instruction de modification de données spécifique (INSERT, UPDATEou DELETE), la vue correspondante est modifiable par le biais de cette instruction. Pour plus d’informations sur INSTEAD OF les déclencheurs, consultez Déclencheurs DML.

• Vues partitionnée

  Si la vue est dite « partitionnée », elle peut être mise à jour sous certaines conditions. Au besoin, le Moteur de base de données fait la distinction entre une vue partitionnée locale d'une part, car cette vue ainsi que toutes les tables impliquées à sa création figurent sur le même serveur SQL Server, et une vue partitionnée distribuée d'autre part, car au moins l'une des tables de la vue se trouve sur un serveur différent, voire distant.

Vues partitionnées

Une vue partitionnée est une vue définie par une UNION ALL table membre structurée de la même façon, mais stockée séparément en tant que plusieurs tables dans la même instance de SQL Server ou dans un groupe d’instances autonomes de serveurs SQL Server, appelées serveurs de base de données fédérés.

Notes

Le partitionnement des données en local s'effectue de préférence par le biais de tables partitionnées. Pour plus d’informations, consultez Tables et index partitionnés.

Lorsque vous concevez un schéma de partitionnement, il doit être clair quelles données appartiennent à chaque partition. Par exemple, les données de la table Customers sont réparties entre trois tables membres, chacune sur un emplacement serveur distinct : Customers_33 sur Server1, Customers_66 sur Server2 et Customers_99 sur Server3.

Une vue partitionnée sur Server1 est définie de la façon suivante :

--Partitioned view as defined on Server1  
CREATE VIEW Customers  
AS  
--Select from local member table.  
SELECT *  
FROM CompanyData.dbo.Customers_33  
UNION ALL  
--Select from member table on Server2.  
SELECT *  
FROM Server2.CompanyData.dbo.Customers_66  
UNION ALL  
--Select from member table on Server3.  
SELECT *  
FROM Server3.CompanyData.dbo.Customers_99;  

En général, une vue est dite partitionnée si elle se présente sous la forme suivante :

SELECT <select_list1>  
FROM T1  
UNION ALL  
SELECT <select_list2>  
FROM T2  
UNION ALL  
...  
SELECT <select_listn>  
FROM Tn;  

Conditions de création d’affichages partitionnés

1. La list de sélection

   • Dans la liste des colonnes de la définition de la vue, sélectionnez toutes les colonnes dans les tables membres.

   • Vérifiez que les colonnes de position ordinale identique de chaque select list sont de même type, notamment en ce qui concerne les classements. Il n’est pas suffisant que les colonnes soient des types implicitement convertibles, comme c’est généralement le cas pour UNION.

     De plus, au moins une colonne (par exemple <col>) doit apparaître dans toutes les listes SELECT à la même position ordinale. Définissez <col> de façon à ce que les tables membres T1, ..., Tn aient des contraintes CHECK C1, ..., Cn définies pour <col>, respectivement.

     La contrainte C1 définie sur la table T1 doit se présenter sous la forme suivante :

     C1 ::= < simple_interval > [ OR < simple_interval > OR ...]  
     < simple_interval > :: =   
     < col > { < | > | \<= | >= | = < value >}   
     | < col > BETWEEN < value1 > AND < value2 >  
     | < col > IN ( value_list )  
     | < col > { > | >= } < value1 > AND  
     < col > { < | <= } < value2 >  
     

   • La définition des contraintes doit permettre à toute valeur spécifiée de <col> de satisfaire au plus une des contraintes C1, ..., Cn, de telle sorte que les contraintes forment un ensemble d’intervalles disjoints ou sans chevauchement. La colonne <col> sur laquelle les contraintes disjointes sont définies est appelée colonne de partitionnement. La colonne de partitionnement peut avoir différents noms dans les tables sous-jacentes. Les contraintes doivent être dans un état activé et approuvé pour répondre aux conditions précédemment mentionnées de la colonne de partitionnement. Si les contraintes sont désactivées, réactivez la vérification des contraintes à l’aide de CHECK CONSTRAINT *constraint_name*l’option ALTER TABLE , puis utilisez l’option WITH CHECK pour les valider.

     Voici des exemples d'ensembles valides de contraintes :

     { [col < 10], [col between 11 and 20] , [col > 20] }  
     { [col between 11 and 20], [col between 21 and 30], [col between 31 and 100] }  
     

   • La même colonne ne peut être utilisée qu'une seule fois dans la liste de sélection.

2. Colonne de partitionnement

   • La colonne de partitionnement fait partie de la clé primaire de la table.

   • Il ne peut pas s’agir d’une colonne calculée, d’une colonne d’identité, d’une colonne par défaut ou d’une colonne de type timestamp.

   • Si une colonne d'une table membre comporte plusieurs contraintes, le moteur de bases de données ignore toutes les contraintes et n'en tient pas compte pour déterminer si la vue est ou non une vue partitionnée. Pour que les conditions associées à la vue partitionnée soient remplies, vérifiez qu’il n’y a qu’une seule contrainte de partitionnement sur la colonne de partitionnement.

   • Aucune restriction ne s'applique sur la possibilité de mettre à jour la colonne de partitionnement.

3. Tables membres ou tables sous-jacentes T1, ..., Tn

   • Les tables peuvent être des tables locales ou des tables provenant d'autres serveurs SQL Server référencées par le biais d'un nom à quatre composantes ou d'un nom basé sur OPENDATASOURCE ou OPENROWSET. La syntaxe OPENDATASOURCE et OPENROWSET permet de spécifier le nom d'une table, mais pas une requête directe. Pour plus d’informations, consultez OPENDATASOURCE (Transact-SQL) et OPENROWSET (Transact-SQL).

     Si une ou plusieurs tables membres sont distantes, la vue est appelée vue partitionnée de données distribuées, et des conditions supplémentaires s'appliquent. Ces conditions sont présentées plus loin dans cette section.

   • La même table ne peut pas apparaître deux fois dans l’ensemble de tables qui sont combinées à l’instruction UNION ALL .

   • Dans les tables membres, il est impossible de créer des index sur les colonnes calculées de la table.

   • Toutes les contraintes PRIMARY KEY des tables membres doivent être appliquées sur un nombre identique de colonnes.

   • Toutes les tables membres de la vue doivent avoir le même paramètre de remplissage ANSI. Cela peut être défini à l’aide de l’option options utilisateur dans sp_configure ou de l’instruction SET.

Conditions de modification des données dans les vues partitionnée

Les restrictions suivantes s'appliquent aux instructions qui modifient les données dans les vues partitionnées :

• L’instruction INSERT fournit des valeurs pour toutes les colonnes de la vue, même si les tables membres sous-jacentes ont une DEFAULT contrainte pour ces colonnes ou si elles autorisent des NULL valeurs. Pour les colonnes de table membre qui ont DEFAULT des définitions, les instructions ne peuvent pas utiliser explicitement le mot clé DEFAULT.

• La valeur insérée dans la colonne de partitionnement satisfait au moins l’une des contraintes sous-jacentes ; sinon, l’action d’insertion échoue avec une violation de contrainte.

• UPDATE les instructions ne peuvent pas spécifier le DEFAULT mot clé comme valeur dans la SET clause, même si la colonne a une DEFAULT valeur définie dans la table membre correspondante.

• Les colonnes de la vue qui sont une colonne d’identité dans une ou plusieurs tables membres ne peuvent pas être modifiées à l’aide d’une ou INSERT d’une UPDATE instruction.

• Si l’une des tables membres contient une colonne d’horodatage, les données ne peuvent pas être modifiées à l’aide d’une instruction ou INSERT d’une UPDATE instruction.

• Si l’une des tables membres contient un déclencheur ou une ON UPDATE CASCADE/SET NULL/SET DEFAULTON DELETE CASCADE/SET NULL/SET DEFAULT contrainte, la vue ne peut pas être modifiée.

• INSERT, UPDATEet DELETE les actions sur une vue partitionnée ne sont pas autorisées s’il existe une jointure automatique avec la même vue ou avec l’une des tables membres de l’instruction.

• L’importation en bloc de données dans une vue partitionnée n’est pas prise en charge par ou par bcp les BULK INSERTINSERT ... SELECT * FROM OPENROWSET(BULK...) instructions. Toutefois, vous pouvez insérer plusieurs lignes dans une vue partitionnée en utilisant l’instruction INSERT.

  Notes

  Pour mettre à jour une vue partitionnée, l’utilisateur doit disposer INSERTUPDATEdes autorisations et DELETE des autorisations sur les tables membres.

Conditions supplémentaires pour les vues partitionnée distribuées

Dans le cas des vues partitionnées distribuées, qui impliquent une ou plusieurs tables membres distantes, les conditions supplémentaires suivantes s'appliquent :

• Une transaction distribuée est démarrée pour garantir l’atomicité entre tous les nœuds affectés par la mise à jour.

• Définissez l’option XACT_ABORT SETON sur INSERT, UPDATEou DELETE les instructions à utiliser.

• Toutes les colonnes de tables distantes de type smallmoney qui sont référencées dans une vue partitionnée sont mappées en money. Par conséquent, les colonnes correspondantes dans les tables locales (de position ordinale identique dans la liste de sélection) doivent également être de type money.

• Quand le niveau de compatibilité de la base de données est 110 et supérieur, toutes les colonnes des tables distantes de type smalldatetime qui sont référencées dans une vue partitionnée sont mappées en smalldatetime. Les colonnes correspondantes dans les tables locales (de position ordinale identique dans la liste de sélection) doivent être de type smalldatetime. Il s’agit d’un changement de comportement par rapport aux versions antérieures de SQL Server dans lequel toutes les colonnes des tables distantes de type smalldatetime référencées dans une vue partitionnée sont mappées en datetime et les colonnes correspondantes dans les tables locales doivent être de type datetime. Pour plus d’informations, consultez ALTER DATABASE - Niveau de compatibilité (Transact-SQL).

• Tout serveur lié dans une vue partitionnée ne peut pas être un serveur dont la liaison constitue un bouclage. En d'autres termes, un serveur lié ne peut pas pointer vers la même instance de SQL Server.

Le paramètre de l’option SET ROWCOUNT est ignoré pour INSERT, UPDATEet DELETE les actions qui impliquent des vues partitionnée pouvant être mises à jour et des tables distantes.

Lorsque les tables membres et la définition de la vue partitionnée sont implémentées, l'optimiseur de requête de SQL Server crée des plans intelligents qui utilisent efficacement les requêtes pour accéder aux données des tables membres. Avec les CHECK définitions de contrainte, le processeur de requêtes mappe la distribution des valeurs de clé entre les tables membres. Lorsqu’un utilisateur émet une requête, le processeur de requêtes compare le mappage aux valeurs spécifiées dans la WHERE clause et génère un plan d’exécution avec une quantité minimale de transfert de données entre les serveurs membres. Par conséquent, si certaines tables membres se trouvent dans des serveurs distants, l’instance de SQL Server résout les requêtes distribuées afin que la quantité de données distribuées qui doivent être transférées soit minimale.

Considérations relatives à la réplication

Pour créer des vues partitionnées sur des tables membres entrant en jeu dans une réplication, les points suivants sont à prendre en considération :

• Si les tables sous-jacentes sont impliquées dans une réplication de fusion ou transactionnelle avec mise à jour des abonnements, vérifiez que la colonne uniqueidentifier est également incluse dans la liste de sélection.

  Toutes les INSERT actions dans la vue partitionnée doivent fournir une NEWID() valeur pour la colonne uniqueidentifier . Toutes les actions UPDATE sur la colonne uniqueidentifier doivent fournir NEWID() comme valeur, car le mot clé DEFAULT ne peut pas être utilisé.

• La réplication de mises à jour opérées par le biais de la vue revient à répliquer des tables tirées de deux bases de données différentes : les tables sont servies par différents agents de réplication ; l'ordre des mises à jour ne peut ainsi être garanti.

Autorisations

Nécessite l'autorisation CREATE VIEW dans la base de données et l'autorisation ALTER sur le schéma dans lequel la vue est créée.

Exemples

Les exemples suivants utilisent la base de données AdventureWorks2022 ou AdventureWorksDW2022.

R : Utiliser CREATE VIEW pour créer une vue

L’exemple suivant crée une vue à l’aide d’une SELECT instruction. Une vue simple est utile lorsque vous interrogez régulièrement une combinaison de colonnes. Les données de cette vue sont tirées des tables HumanResources.Employee et Person.Person de la base de données AdventureWorks2022. Ces données fournissent les noms et les informations relatives à la date d'embauche des employés de Adventure Works Cycles. La vue doit pouvoir être créée par la personne chargée de suivre les dates anniversaires d'embauche mais sans pour autant l'autoriser à accéder à toutes les données de ces tables.

CREATE VIEW hiredate_view  
AS
SELECT p.FirstName, p.LastName, e.BusinessEntityID, e.HireDate  
FROM HumanResources.Employee AS e   
JOIN Person.Person AS p ON e.BusinessEntityID = p.BusinessEntityID ;  
GO  

B. Utiliser WITH ENCRYPTION

Cet exemple utilise l'option WITH ENCRYPTION et montre les colonnes calculées, les colonnes renommées et les colonnes multiples.

S’applique à : SQL Server 2008 (10.0.x) et versions ultérieures, et Azure SQL Database.

CREATE VIEW Purchasing.PurchaseOrderReject  
WITH ENCRYPTION  
AS  
SELECT PurchaseOrderID, ReceivedQty, RejectedQty,   
    RejectedQty / ReceivedQty AS RejectRatio, DueDate  
FROM Purchasing.PurchaseOrderDetail  
WHERE RejectedQty / ReceivedQty > 0  
AND DueDate > CONVERT(DATETIME,'20010630',101) ;  
GO  

Chapitre C. Utiliser WITH CHECK OPTION

Cet exemple montre une vue appelée dbo.SeattleOnly se reportant à cinq tables et n'autorisant des modifications de données que pour les employés vivant à Seattle.

CREATE VIEW dbo.SeattleOnly  
AS  
SELECT p.LastName, p.FirstName, e.JobTitle, a.City, sp.StateProvinceCode  
FROM HumanResources.Employee e  
INNER JOIN Person.Person p  
ON p.BusinessEntityID = e.BusinessEntityID  
    INNER JOIN Person.BusinessEntityAddress bea   
    ON bea.BusinessEntityID = e.BusinessEntityID   
    INNER JOIN Person.Address a   
    ON a.AddressID = bea.AddressID  
    INNER JOIN Person.StateProvince sp   
    ON sp.StateProvinceID = a.StateProvinceID  
WHERE a.City = 'Seattle'  
WITH CHECK OPTION ;  
GO  

D. Utiliser des fonctions intégrées dans une vue

L'exemple suivant illustre la définition d'une vue qui inclut une fonction intégrée. Si vous utilisez des fonctions, vous devez attribuer un nom à la colonne dérivée.

CREATE VIEW Sales.SalesPersonPerform  
AS  
SELECT TOP (100) SalesPersonID, SUM(TotalDue) AS TotalSales  
FROM Sales.SalesOrderHeader  
WHERE OrderDate > CONVERT(DATETIME,'20001231',101)  
GROUP BY SalesPersonID;  
GO  

E. Utiliser des données partitionnée

L'exemple suivant s'appuie sur les tables nommées SUPPLY1, SUPPLY2, SUPPLY3 et SUPPLY4. Ces tables correspondent aux tables de fournisseurs de quatre bureaux situés dans différentes régions.

--Create the tables and insert the values.  
CREATE TABLE dbo.SUPPLY1 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 1 and 150),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY2 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 151 and 300),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY3 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 301 and 450),  
supplier CHAR(50)  
);  
CREATE TABLE dbo.SUPPLY4 (  
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 451 and 600),  
supplier CHAR(50)  
);  
GO  
--Create the view that combines all supplier tables.  
CREATE VIEW dbo.all_supplier_view  
WITH SCHEMABINDING  
AS  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY1  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY2  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY3  
UNION ALL  
SELECT supplyID, supplier  
  FROM dbo.SUPPLY4;  
GO
INSERT dbo.all_supplier_view VALUES ('1', 'CaliforniaCorp'), ('5', 'BraziliaLtd')    
, ('231', 'FarEast'), ('280', 'NZ')  
, ('321', 'EuroGroup'), ('442', 'UKArchip')  
, ('475', 'India'), ('521', 'Afrique');  
GO  

Exemples : Azure Synapse Analytics et Analytics Platform System (PDW)

F. Créer une vue en joignant deux tables

L’exemple suivant crée une vue à l’aide d’une instruction SELECT avec un OUTER JOIN. Les résultats de la requête de jointure s’affichent dans la vue.

CREATE VIEW view1  
AS 
SELECT fis.CustomerKey, fis.ProductKey, fis.OrderDateKey, 
  fis.SalesTerritoryKey, dst.SalesTerritoryRegion  
FROM FactInternetSales AS fis   
LEFT OUTER JOIN DimSalesTerritory AS dst   
ON (fis.SalesTerritoryKey=dst.SalesTerritoryKey);  

Contenu connexe

• MODIFIER LA TABLE (Transact-SQL)
• ALTER VIEW (Transact-SQL)
• DELETE (Transact-SQL)
• DROP VIEW (Transact-SQL)
• INSERT (Transact-SQL)
• Créer une procédure stockée
• sys.dm_sql_referenced_entities (Transact-SQL)
• sys.dm_sql_referencing_entities (Transact-SQL)
• sp_help (Transact-SQL)
• sp_helptext (Transact-SQL)
• sp_refreshview (Transact-SQL)
• sp_rename (Transact-SQL)
• sys.views (Transact-SQL)
• UPDATE (Transact-SQL)
• EVENTDATA (Transact-SQL)