CREATE VIEW (Transact-SQL)

Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Piattaforma di strumenti analitici (PDW) Endpoint di analisi SQL in Microsoft Fabric Warehouse in Microsoft Fabric

Crea una tabella virtuale il cui contenuto (colonne e righe) è definito da una query. Utilizzare questa istruzione per creare una vista dei dati in una o più tabelle nel database. Ad esempio, è possibile utilizzare una vista per gli scopi seguenti:

• Per analizzare, semplificare e personalizzare la visualizzazione del database per ogni utente.

• Come meccanismo di sicurezza grazie al quale è possibile consentire agli utenti di accedere ai dati tramite una vista, senza concedere loro le autorizzazioni di accesso alle tabelle di base sottostanti.

• Per fornire un'interfaccia compatibile con le versioni precedenti con cui emulare una tabella il cui schema è stato modificato.

Convenzioni relative alla sintassi Transact-SQL

Sintassi

-- Syntax for SQL Server and 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 ]
}

-- Syntax for Azure Synapse Analytics and 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>  

-- Syntax for [!INCLUDE [fabric](../../includes/fabric.md)]
  
CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
AS <select_statement>   
[;]  
  
<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Argomenti

OR ALTER

Si applica a: database SQL di Azure e SQL Server, a partire da SQL Server 2016 (13.x) SP1.

Modifica in modo condizionale la vista solo se esiste già.

schema_name
Nome dello schema a cui appartiene la vista.

view_name
Nome della vista. I nomi di vista devono essere conformi alle regole per gli identificatori. Il nome del proprietario della vista è facoltativo.

column
Nome da assegnare a una colonna della vista. Il nome della colonna è necessario solo quando una colonna deriva da un'espressione aritmetica, una funzione o una costante, quando due o più colonne potrebbero altrimenti avere lo stesso nome (in genere a causa di un join) oppure quando a una colonna di una vista viene assegnato un nome diverso rispetto alla colonna da cui deriva. È inoltre possibile assegnare nomi di colonna nell'istruzione SELECT.

Se column viene omesso, le colonne della vista acquisiscono gli stessi nomi delle colonne dell'istruzione SELECT.

Nota

Nelle colonne di una vista, le autorizzazioni assegnate per un nome di colonna rimangono valide tra istruzioni CREATE VIEW e ALTER VIEW, indipendentemente dall'origine dei dati sottostanti. Se, ad esempio, vengono concesse autorizzazioni per la colonna SalesOrderID in un'istruzione CREATE VIEW, un'istruzione ALTER VIEW può assegnare alla colonna SalesOrderID un nome diverso, ad esempio OrderRef, e mantenere le autorizzazioni associate alla vista che usa SalesOrderID.

AS

Specifica le operazioni che la vista deve eseguire.

select_statement
Istruzione SELECT che definisce la vista. Nell'istruzione è possibile specificare più di una tabella e altre viste. Per selezionare gli oggetti a cui viene fatto riferimento nella clausola SELECT della vista creata è necessario disporre di autorizzazioni appropriate.

Non è necessario che una vista sia un semplice subset delle righe e delle colonne di una tabella specifica. È possibile creare una vista che utilizza più tabelle o altre viste tramite una clausola SELECT del grado di complessità desiderato.

In una definizione di vista indicizzata l'istruzione SELECT deve essere riferita a una sola tabella oppure includere un JOIN tra più tabelle con aggregazioni facoltative.

Le clausole SELECT utilizzate in una definizione di vista non possono includere gli elementi seguenti:

• Una clausola ORDER BY, a meno che nell'elenco di selezione dell'istruzione SELECT non sia presente anche una clausola TOP

  Importante

  La clausola ORDER BY viene utilizzata esclusivamente per determinare le righe restituite dalla clausola TOP oppure OFFSET nella definizione della vista. La clausola ORDER BY non garantisce risultati ordinati in caso di query sulla vista, a meno che tale clausola non venga specificata anche nella query.

• Parola chiave INTO

• Clausola OPTION

• Un riferimento a una tabella temporanea o a una variabile di tabella

Poiché select_statement usa l'istruzione SELECT, è possibile usare gli hint <join_hint> e <table_hint> come specificato nella clausola FROM. Per altre informazioni, vedere FROM (Transact-SQL) e SELECT (Transact-SQL).

In select_statement è possibile usare funzioni e più istruzioni SELECT separate dall'operatore UNION o UNION ALL.

CHECK OPTION

Forza il rispetto del set di criteri specificato in select_statement per tutte le istruzioni di modifica dei dati eseguite sulla vista. Quando una riga viene modificata tramite una vista, la clausola WITH CHECK OPTION assicura che i dati rimangano visibili nella vista dopo il commit della modifica.

Nota

CHECK OPTION si applica solo agli aggiornamenti eseguiti tramite la vista. Non è applicabile agli aggiornamenti eseguiti direttamente nelle tabelle sottostanti di una vista.

ENCRYPTION

Si applica a: SQL Server 2008 (10.0.x) e versioni successive e database SQL di Azure.

Esegue la crittografia delle voci della tabella sys.syscomments contenenti il testo dell'istruzione CREATE VIEW. Se si utilizza WITH ENCRYPTION, la vista non viene pubblicata nell'ambito della replica di SQL Server.

SCHEMABINDING

Associa la vista allo schema della tabella o delle tabelle sottostanti. Quando la clausola SCHEMABINDING viene specificata, non è possibile apportare alla tabella o alle tabelle di base modifiche che hanno effetto sulla definizione della vista. È necessario prima modificare o eliminare la definizione della vista per rimuovere le dipendenze dalla tabella da modificare. Quando si usa SCHEMABINDING, l'argomento select_statement deve includere i nomi composti da due parti (schema.object) delle tabelle, delle visualizzazioni o delle funzioni definite dall'utente a cui viene fatto riferimento. Tutti gli oggetti a cui viene fatto riferimento devono essere presenti nello stesso database.

Le viste o le tabelle che fanno parte di una vista creata con la clausola SCHEMABINDING non possono essere eliminate, a meno che la vista non venga eliminata o modificata in modo che non sia più associata a uno schema. In caso contrario, il motore di database genera un errore. Inoltre, l'esecuzione di istruzioni ALTER TABLE su tabelle che fanno parte di viste associate a schema ha esito negativo se tali istruzioni modificano la definizione della vista.

Nota

In Azure Synapse Analytics le viste attualmente non supportano l'associazione allo schema. Per altre informazioni, vedere Viste T-SQL con pool T-SQL dedicato e pool SQL serverless in Azure Synapse Analytics.

VIEW_METADATA

Specifica che l'istanza di SQL Server dovrà restituire alle API DB-Library, ODBC e OLE DB le informazioni sui metadati relativi alla vista anziché alla tabella o alle tabelle di base quando vengono richiesti metadati in modalità browse per una query che fa riferimento alla vista. I metadati in modalità browse sono metadati aggiuntivi che l'istanza di SQL Server restituisce a queste API sul lato client. Questi metadati consentono alle API sul lato client di implementare cursori sul lato client aggiornabili. I metadati in modalità browse includono informazioni sulla tabella di base a cui appartengono le colonne del set di risultati.

Per le viste create con VIEW_METADATA, i metadati in modalità browse restituiscono il nome della vista anziché i nomi delle tabelle di base nella descrizione delle colonne della vista nel set di risultati.

Quando si crea una vista con la clausola WITH VIEW_METADATA, tutte le relative colonne, escluse quelle di tipo timestamp, sono aggiornabili se la vista include trigger INSTEAD OF INSERT o INSTEAD OF UPDATE. Per ulteriori informazioni sulle viste aggiornabili, vedere la sezione Osservazioni.

Osservazioni:

È possibile creare una vista solo nel database corrente. CREATE VIEW deve essere la prima istruzione di un batch di query. Una vista può includere al massimo 1.024 colonne.

Quando si esegue una query tramite una vista, il motore di database verifica che tutti gli oggetti di database a cui viene fatto riferimento nell'istruzione esistano e siano validi nel contesto dell'istruzione, nonché che le istruzioni di modifica dei dati non violino le regole di integrità dei dati. Se la verifica ha esito negativo, viene visualizzato un messaggio di errore. In caso contrario, l'azione viene convertita automaticamente in un'operazione sulla tabella o sulle tabelle sottostanti.

Se si cerca di usare una vista che dipende da una tabella o una vista rimossa, il motore di database genera un messaggio di errore. Se viene creata una nuova tabella o vista per sostituire quella eliminata e la struttura della nuova tabella non è diversa rispetto alla tabella di base precedente, la vista risulta di nuovo utilizzabile. Se la struttura della nuova tabella o vista è diversa, la vista deve essere eliminata e ricreata.

Se una vista non viene creata con la clausola SCHEMABINDING, eseguire sp_refreshview quando vengono apportate modifiche agli oggetti sottostanti la vista che influiscono sulla definizione di tale vista. In caso contrario, le query sulla vista possono generare risultati imprevisti.

Quando si crea una vista, le relative informazioni vengono archiviate nelle viste del catalogo seguenti: sys.views, sys.columns e sys.sql_expression_dependencies. Il testo dell'istruzione CREATE VIEW viene archiviato nella vista del catalogo sys.sql_modules.

Una query che usa un indice su una vista definita tramite espressioni numeric o float può generare un risultato diverso rispetto a una query simile che non usa l'indice sulla vista. Tale differenza può essere dovuta a errori di arrotondamento generati durante l'esecuzione di operazioni INSERT, DELETE o UPDATE sulle tabelle sottostanti.

Il motore di database salva le impostazioni di SET QUOTED_IDENTIFIER e SET ANSI_NULLS quando viene creata una vista. Queste impostazioni originali vengono utilizzate per analizzare la vista quando viene utilizzata. Pertanto, tutte le impostazioni di sessione del client per SET QUOTED_IDENTIFIER e SET ANSI_NULLS non hanno effetto sulla definizione della vista durante l'accesso alla vista.

Viste aggiornabili

Nota

In Azure Synapse Analytics, attualmente le viste aggiornabili, i trigger DML (di tipo AFTER o INSTEAD OF) e le viste partizionate non sono supportate. Per altre informazioni, vedere Viste T-SQL con pool T-SQL dedicato e pool SQL serverless in Azure Synapse Analytics.

È possibile modificare i dati di una tabella di base sottostante tramite una vista solo se vengono soddisfatti i requisiti seguenti:

• Tutte le modifiche, incluse le istruzioni UPDATE, INSERT e DELETE, devono fare riferimento a colonne di una sola tabella di base.

• Le colonne modificate nella vista devono fare riferimento direttamente ai dati sottostanti nelle colonne della tabella. Le colonne non possono essere derivate in altro modo, ad esempio tramite:

  • Una funzione di aggregazione: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP, VAR e VARP.

  • Un calcolo. La colonna non può essere calcolata tramite un'espressione che utilizza altre colonne. Le colonne create mediante gli operatori sui set UNION, UNION ALL, CROSSJOIN, EXCEPT e INTERSECT sono considerate un calcolo e non sono aggiornabili.

• Le colonne da modificare non sono interessate da clausole GROUP BY, HAVING o DISTINCT.

• La clausola TOP non può essere usata in tutte le posizioni dell'argomento select_statement della vista in combinazione con la clausola WITH CHECK OPTION.

Le restrizioni sopra indicate sono valide sia per qualsiasi sottoquery nella clausola FROM della vista sia per la vista stessa. In genere, il motore di database deve essere in grado di tracciare senza ambiguità le modifiche dalla definizione della vista a una tabella di base. Per altre informazioni, vedere Modificare i dati tramite una vista.

Se le restrizioni sopra indicate non consentono di modificare i dati direttamente tramite una vista, è possibile ricorrere alle soluzioni seguenti:

• Trigger INSTEAD OF

  È possibile creare trigger INSTEAD OF per una vista in modo da renderla aggiornabile. Questo trigger viene eseguito in sostituzione dell'istruzione di modifica dei dati in cui è definito e consente all'utente di specificare il set di azioni che devono essere eseguite per elaborare l'istruzione di modifica dei dati. Pertanto, se è disponibile un trigger INSTEAD OF per una vista in un'istruzione di modifica dei dati specifica (INSERT, UPDATE o DELETE), la vista corrispondente risulta aggiornabile tramite l'istruzione. Per altre informazioni sui trigger INSTEAD OF, vedere Trigger DML.

• Viste partizionate

  Se la vista è partizionata, è aggiornabile ma con particolari restrizioni. Quando necessario, il motore di database effettua una distinzione tra viste partizionate locali, ovvero le viste nelle quali tutte le tabelle coinvolte e la vista stessa si trovano nella stessa istanza di SQL Server, e viste partizionate distribuite, ovvero le viste nelle quali almeno una tabella si trova in un server diverso o remoto.

Viste partizionate

Nota

In Azure Synapse Analytics le viste attualmente partizionate non sono supportate. Per altre informazioni, vedere Viste T-SQL con pool T-SQL dedicato e pool SQL serverless in Azure Synapse Analytics.

Una vista partizionata è una vista definita tramite un'istruzione UNION ALL eseguita su tabelle membro con la stessa struttura, ma archiviate separatamente come più tabelle nella stessa istanza di SQL Server oppure in un gruppo di istanze autonome di server SQL Server a cui si fa riferimento come federazione di server database.

Nota

Il metodo consigliato per il partizionamento locale dei dati in un server prevede l'utilizzo di tabelle partizionate. Per ulteriori informazioni, vedere Partitioned Tables and Indexes.

Durante la progettazione di uno schema di partizione, è necessario individuare con chiarezza i dati appartenenti a ogni partizione. Ad esempio, i dati della tabella Customers vengono distribuiti in tre tabelle membro su tre server: Customers_33 su Server1, Customers_66 su Server2 e Customers_99 su Server3.

Una vista partizionata in Server1 viene definita nel modo seguente:

--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;  

In generale, una vista viene definita partizionata se utilizza il formato seguente:

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

Requisiti per la creazione di viste partizionate

1. Elenchi di selezione (select list)

   • Nell'elenco di colonne della definizione della vista, selezionare tutte le colonne nelle tabelle membro.

   • Assicurarsi che le colonne nella stessa posizione ordinale in ogni oggetto select list siano dello stesso tipo, incluse le regole di confronto. Non è sufficiente che il tipo di dati delle colonne supporti la conversione implicita, come nel caso di operazioni UNION.

     Inoltre, è necessario che almeno una colonna, ad esempio <col>, sia presente in tutti gli elenchi di selezione nella stessa posizione ordinale. Definire <col> in modo che le tabelle membro T1, ..., Tn abbiano, rispettivamente, vincoli CHECK C1, ..., Cn definiti in <col>.

     Il vincolo C1 definito nella tabella T1 deve avere il formato seguente:

     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 >  
     

   • I vincoli devono essere tali per cui qualsiasi valore di <col> specificato possa soddisfare al massimo uno dei vincoli C1, ..., Cn, in modo che i vincoli formino un set di intervalli disgiunti o non sovrapposti. La colonna <col> in cui sono definiti i vincoli disgiunti è denominata colonna di partizionamento. Si noti che nelle tabelle sottostanti tale colonna può avere nomi diversi. Per soddisfare le condizioni precedenti della colonna di partizionamento, i vincoli devono essere abilitati e attendibili. Se i vincoli sono disabilitati, è necessario riabilitare il controllo dei vincoli tramite l'opzione CHECK CONSTRAINT constraint_name dell'istruzione ALTER TABLE e convalidarli tramite l'opzione WITH CHECK.

     Negli esempi seguenti vengono illustrati alcuni set di vincoli validi:

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

   • Nell'elenco di selezione non è consentito utilizzare più volte la stessa colonna.

2. Colonna di partizionamento

   • Deve fare parte della colonna PRIMARY KEY della tabella.

   • Non può essere una colonna calcolata, Identity, predefinita o timestamp.

   • Se una colonna di una tabella membro ha più vincoli, vengono ignorati tutti i vincoli, anche quando è necessario determinare se la vista è partizionata. Per soddisfare le condizioni della vista partizionata, assicurarsi che ci sia un solo vincolo di partizionamento nella colonna di partizionamento.

   • Non sono previste restrizioni per quanto concerne l'aggiornabilità della colonna di partizionamento.

3. Tabelle membro o tabelle sottostanti T1, ..., Tn

   • Le tabelle possono essere locali o presenti in altri computer che eseguono SQL Server a cui viene fatto riferimento tramite un nome composto da quattro parti oppure un nome basato su OPENDATASOURCE o OPENROWSET. La sintassi di OPENDATASOURCE e OPENROWSET consente di specificare un nome di tabella, ma non una query pass-through. Per altre informazioni, vedere OPENDATASOURCE (Transact-SQL) e OPENROWSET (Transact-SQL).

     Se una o più tabelle membro sono remote, la vista viene definita vista partizionata distribuita ed è necessario rispettare alcuni ulteriori requisiti descritti di seguito in questa sezione.

   • Non è possibile inserire una stessa tabella due volte nel set di tabelle combinate tramite l'istruzione UNION ALL.

   • Le tabelle membro non possono includere indici creati su colonne calcolate della tabella.

   • Le tabelle membro hanno i vincoli PRIMARY KEY nello stesso numero di colonne.

   • Tutte le tabelle membro della vista hanno la stessa impostazione di riempimento ANSI. Questa impostazione può essere configurata tramite l'opzione user options della stored procedure sp_configure oppure tramite l'istruzione SET.

Requisiti per la modifica dei dati in viste partizionate

Le istruzioni che modificano i dati in viste partizionate sono soggette alle restrizioni seguenti:

• L'istruzione INSERT fornisce valori per tutte le colonne della vista, anche se le tabelle membro sottostanti hanno un vincolo DEFAULT per tali colonne o ammettono valori Null. Per le colonne delle tabelle membro che includono definizioni DEFAULT, nelle istruzioni non è consentito specificare la parola chiave DEFAULT in modo esplicito.

• Il valore inserito nella colonna di partizionamento soddisfa almeno uno dei vincoli sottostanti. In caso contrario, l'operazione di inserimento provoca una violazione di vincolo e ha esito negativo.

• Nelle istruzioni UPDATE non è possibile specificare la parola chiave DEFAULT come valore nella clausola SET, anche se alla colonna è associato un valore DEFAULT definito nella tabella membro corrispondente.

• Le colonne Identity della vista incluse in una o più tabelle membro non possono essere modificate tramite un'istruzione INSERT o UPDATE.

• Se una delle tabelle membro include una colonna di tipo timestamp, non è possibile modificare i dati tramite un'istruzione INSERT o UPDATE.

• Se una delle tabelle membro include un trigger oppure un vincolo ON UPDATE CASCADE/SET NULL/SET DEFAULT o ON DELETE CASCADE/SET NULL/SET DEFAULT, la vista non può essere modificata.

• Le operazioni INSERT, UPDATE e DELETE eseguite su una vista partizionata non sono consentite se includono un self join con tale vista o con una delle tabelle membro.

• L'importazione bulk dei dati in una vista partizionata non è supportata da bcp o BULK INSERT e INSERT ... ISTRUZIONI SELECT * FROM OPENROWSET(BULK...). È tuttavia possibile inserire più righe in una vista partizionata usando l'istruzione INSERT.

  Nota

  Per aggiornare una vista partizionata, l'utente deve disporre delle autorizzazioni INSERT, UPDATE e DELETE per le tabelle membro.

Requisiti aggiuntivi per le viste partizionate distribuite

Per le viste partizionate distribuite, ovvero le viste nelle quali una o più tabelle membro sono remote, devono essere soddisfatti i requisiti aggiuntivi seguenti:

• Per garantire l'atomicità in tutti i nodi interessati dall'aggiornamento, viene avviata una transazione distribuita.

• Per consentire il corretto funzionamento delle istruzioni INSERT, UPDATE o DELETE, impostare l'opzione XACT_ABORT SET su ON.

• Per tutte le colonne delle tabelle remote di tipo smallmoney a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come money. Pertanto, anche le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo money.

• Con il livello di compatibilità del database 110 o superiore, viene eseguito il mapping come smalldatetime di tutte le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata. Le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo smalldatetime. Questo comportamento differisce dalle versioni precedenti di SQL Server in cui per le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come datetime e le colonne corrispondenti nelle tabelle locali devono essere di tipo datetime. Per altre informazioni, vedere Livello di compatibilità ALTER DATABASE (Transact-SQL).

• Qualsiasi server collegato nella vista partizionata non può essere di tipo loopback, ovvero non deve puntare alla stessa istanza di SQL Server.

L'impostazione dell'opzione SET ROWCOUNT viene ignorata per le operazioni INSERT, UPDATE e DELETE che coinvolgono viste partizionate aggiornabili e tabelle remote.

Quando sono disponibili le tabelle membro e la definizione della vista partizionata, l'utilità Query Optimizer di SQL Server crea piani intelligenti che usano le query in modo efficiente per l'accesso ai dati delle tabelle membro. Con le definizioni di vincoli CHECK, in Query Processor viene eseguito il mapping della distribuzione dei valori chiave nelle tabelle membro. Quando un utente inoltra una query, viene eseguito un confronto tra il mapping e i valori specificati nella clausola WHERE, quindi viene compilato un piano di esecuzione che comporta il trasferimento di una quantità minima di dati tra i server membri. Pertanto, sebbene sia possibile che alcune tabelle membro si trovino in server remoti, l'istanza di SQL Server risolve le query distribuite in modo che la quantità di dati distribuiti da trasferire sia minima.

Requisiti per la replica

Per creare viste partizionate di tabelle membro coinvolte nella replica, devono essere soddisfatti i requisiti seguenti:

• Se le tabelle sottostanti sono coinvolte nella replica transazionale o di tipo merge con sottoscrizioni aggiornabili, assicurarsi che nell'elenco di selezione sia presente anche la colonna uniqueidentifier.

  Le operazioni INSERT eseguite nella vista partizionata devono specificare un valore NEWID() per la colonna uniqueidentifier. Le operazioni UPDATE eseguite sulla colonna uniqueidentifier devono specificare il valore NEWID() in quanto non è possibile usare la parola chiave DEFAULT.

• La replica di aggiornamenti tramite la vista equivale alla replica di tabelle in due database distinti, ovvero le tabelle vengono gestite da agenti di replica diversi e l'ordine degli aggiornamenti non è prevedibile.

Autorizzazioni

Richiede l'autorizzazione CREATE VIEW per il database e l'autorizzazione ALTER per lo schema in cui viene creata la vista.

Esempi

Negli esempi seguenti viene utilizzato il AdventureWorks2022 database o AdventureWorksDW2022 .

R. Utilizzo di un'istruzione CREATE VIEW semplice

Nell'esempio seguente viene creata una vista tramite l'utilizzo di un'istruzione SELECT semplice. Una vista semplice risulta utile quando vengono eseguite query frequenti su una combinazione di colonne. I dati di questa vista provengono dalle HumanResources.Employee tabelle e Person.Person del database AdventureWorks2022. I dati contengono informazioni sul nome e sulla data di assunzione dei dipendenti di Adventure Works Cycles. È possibile creare la vista per la persona incaricata di tenere traccia del periodo di assunzione dei dipendenti, senza però consentire a tale utente di accedere a tutti i dati di queste tabelle.

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

B. Utilizzo della clausola WITH ENCRYPTION

Nell'esempio seguente viene utilizzata l'opzione WITH ENCRYPTION e vengono illustrate colonne calcolate, colonne rinominate e più colonne.

Si applica a: SQL Server 2008 (10.0.x) e versioni successive e database SQL.

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  
  

C. Utilizzo della clausola WITH CHECK OPTION

Nell'esempio seguente viene illustrata una vista denominata SeattleOnly che fa riferimento a cinque tabelle e consente di applicare modifiche ai dati solo per i dipendenti che risiedono a 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. Utilizzo di funzioni predefinite in una vista

Nell'esempio seguente viene illustrata una definizione di vista che include una funzione predefinita. Quando si utilizzano le funzioni, è necessario specificare un nome di colonna per la colonna derivata.

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. Utilizzo di dati partizionati

Nell'esempio seguente vengono utilizzate le tabelle denominate SUPPLY1, SUPPLY2, SUPPLY3 e SUPPLY4, corrispondenti alle tabelle dei fornitori di quattro uffici dislocati in aree geografiche diverse.

--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  

Esempi: Azure Synapse Analytics e Piattaforma di strumenti analitici (PDW)

F. Creazione di una vista semplice

Nell'esempio seguente viene creata una vista selezionando solo alcune colonne della tabella di origine.

CREATE VIEW DimEmployeeBirthDates AS  
SELECT FirstName, LastName, BirthDate   
FROM DimEmployee;  

G. Creare una vista creando un join di due tabelle

Nell'esempio seguente viene creata una vista tramite un'istruzione SELECT semplice con un elemento OUTER JOIN. I risultati della query join popolano la vista.

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);  

Vedi anche

ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
DELETE (Transact-SQL)
DROP VIEW (Transact-SQL)
INSERT (Transact-SQL)
Creazione di una stored procedure
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)