CREATE VIEW (Transact-SQL)

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példányAzure Synapse AnalyticsElemzési platformrendszer (PDW)SQL Analytics-végpont a Microsoft FabricbenRaktár a Microsoft FabricbenSQL-adatbázis a Microsoft Fabricben

Létrehoz egy virtuális táblát, amelynek tartalmát (oszlopait és sorait) egy lekérdezés határozza meg. Ezzel az utasítással létrehozhatja az adatok nézetét az adatbázis egy vagy több táblájában. Egy nézet például a következő célokra használható:

• Az adatbázis minden egyes felhasználó általi észlelésének fókuszálása, egyszerűsítése és testre szabása érdekében.

• Biztonsági mechanizmusként lehetővé teszi, hogy a felhasználók a nézeten keresztül férhessenek hozzá az adatokhoz anélkül, hogy a felhasználók közvetlenül hozzáférhetnek az alapul szolgáló alaptáblákhoz.

• Visszafelé kompatibilis felület biztosítása egy olyan tábla emulálásához, amelynek sémája megváltozott.

Transact-SQL szintaxis konvenciók

Syntax

Az SQL Server és az Azure SQL Database szintaxisa.

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

Az Azure Synapse Analytics és a párhuzamos adattárház szintaxisa.

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

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

A Microsoft Fabric Data Warehouse és az SQL Analytics-végpont szintaxisa.

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>  

Arguments

VAGY ALTER

A következőkre vonatkozik: Azure SQL Database és SQL Server (az SQL Server 2016 (13.x) SP1-től kezdve).

Feltételesen csak akkor módosítja a nézetet, ha már létezik.

schema_name
Annak a sémának a neve, amelyhez a nézet tartozik.

view_name
A nézet neve. A nézetneveknek az azonosítókra vonatkozó szabályokat kell követnie. A nézet tulajdonosának nevének megadása nem kötelező.

column
A nézetben lévő oszlophoz használandó név. Az oszlopnév csak akkor szükséges, ha egy oszlop egy számtani kifejezésből, egy függvényből vagy egy állandóból származik; ha két vagy több oszlop neve egyébként azonos lehet, általában egy illesztés miatt; vagy ha egy nézetben egy oszlop neve eltér annak az oszlopnak a nevétől, amelyből származik. Az oszlopnevek az utasításban SELECT is hozzárendelhetők.

Ha az oszlop nincs megadva, a nézetoszlopok ugyanazokat a neveket szerzik be, mint az SELECT utasítás oszlopai.

Note

A nézet oszlopaiban az oszlopok nevének engedélyei egy vagy CREATE VIEW több ALTER VIEW utasításra vonatkoznak, függetlenül az alapul szolgáló adatok forrásától. Ha például egy CREATE VIEW utasításban engedélyeket adnak az SalesOrderID oszlophoz, egy ALTER VIEW utasítás más oszlopnévvel is elnevezheti az SalesOrderID oszlopot, például OrderRef, és továbbra is rendelkezik a nézethez SalesOrderIDkapcsolódó engedélyekkel.

AS

Meghatározza a nézet által végrehajtandó műveleteket.

select_statement

A SELECT nézetet meghatározó utasítás. Az utasítás több táblát és más nézetet is használhat. A megfelelő engedélyek szükségesek a létrehozott nézet záradékában SELECT hivatkozott objektumok közül való kiválasztáshoz.

A nézetnek nem kell egy adott tábla sorainak és oszlopainak részhalmazának lennie. Létrehozható olyan nézet, amely egynél több táblát vagy más nézetet használ bármilyen összetettségi záradékkal SELECT .

Indexelt nézetdefiníciókban az SELECT utasításnak egyetlen táblautasításnak vagy opcionális összesítéssel rendelkező többtáblásnak JOIN kell lennie.

A SELECT nézetdefinícióban lévő záradékok nem tartalmazhatják a következőket:

• ZáradékORDER BY, kivéve, ha az utasítás kiválasztási TOP listájában egy záradék is SELECT szerepel

  Important

  A ORDER BY záradék csak a nézetdefiníció vagy TOP záradék által OFFSET visszaadott sorok meghatározására szolgál. A ORDER BY záradék nem garantálja a rendezett eredményeket a nézet lekérésekor, kivéve, ha ORDER BY magát a lekérdezést is megadja.

• A INTO kulcsszó

• A OPTION záradék

• Egy ideiglenes táblára vagy egy táblaváltozóra mutató hivatkozás.

Mivel select_statement az utasítást SELECT használja, a záradékban FROM megadott illesztési tippek és táblázattippek használata érvényes. További információ: FROM (Transact-SQL) és SELECT (Transact-SQL).

A függvények és a több SELECT utasítás elválasztva van egymástól UNION , vagy UNION ALL használhatók select_statement.

JELÖLT

Kényszeríti az összes adatmódosítási utasítást a nézetre, hogy kövesse a select_statement megadott feltételeket. Ha egy sor egy nézeten keresztül módosul, a WITH CHECK OPTION módosítás véglegesítése után az adatok láthatóak maradnak a nézetben.

Note

Az CHECK OPTION egyetlen a nézeten keresztül végrehajtott frissítésekre vonatkozik. Nem alkalmazható a nézet alapjául szolgáló táblákon közvetlenül végrehajtott frissítésekre.

ENCRYPTION

A következővonatkozik: SQL Server 2008 (10.0.x) és újabb verziók, valamint az Azure SQL Database.

Titkosítja a sys.syscomments azon bejegyzéseit, amelyek tartalmazzák az utasítás szövegét CREATE VIEW . A használat WITH ENCRYPTION megakadályozza, hogy a nézet az SQL Server-replikáció részeként legyen közzétéve.

SCHEMABINDING

A nézetet az alapul szolgáló tábla vagy táblák sémájának kötése. Ha SCHEMABINDING meg van adva, az alaptábla vagy táblák nem módosíthatók olyan módon, amely hatással lenne a nézetdefinícióra. Magát a nézetdefiníciót először módosítani vagy elvetni kell a módosítani kívánt tábla függőségeinek eltávolításához. Ha használja SCHEMABINDING, a select_statement tartalmaznia kell a kétrészes neveket (sémát).objektum) a hivatkozott táblák, nézetek vagy felhasználó által definiált függvények közül. Minden hivatkozott objektumnak ugyanabban az adatbázisban kell lennie.

A SCHEMABINDING záradékkal létrehozott nézetben részt vevő nézetek vagy táblák csak akkor elvethetők vagy módosíthatók, hogy ne legyen sémakötése. Ellenkező esetben az adatbázismotor hibát jelez. Emellett a sémakötést tartalmazó nézetekben részt vevő táblákra vonatkozó utasítások végrehajtása ALTER TABLE meghiúsul, ha ezek az utasítások hatással vannak a nézetdefinícióra.

VIEW_METADATA

Megadja, hogy az SQL Server példánya az alaptábla vagy táblák helyett a nézet metaadatait adja vissza a DB-Könyvtárba, az ODBC-be és az OLE DB API-ba, amikor tallózási módú metaadatokat kérnek a nézetre hivatkozó lekérdezéshez. A tallózási módú metaadatok további metaadatok, amelyeket az SQL Server példánya visszatér ezekhez az ügyféloldali API-khoz. Ez a metaadatok lehetővé teszik az ügyféloldali API-k számára, hogy frissíthető ügyféloldali kurzorokat implementáljanak. A tallózási mód metaadatai az eredményhalmaz oszlopaihoz tartozó alaptáblával kapcsolatos információkat tartalmazzák.

A tallózási módú VIEW_METADATAmetaadatok a nézet nevét, és nem az alaptáblaneveket adja vissza, amikor az eredményhalmazban lévő nézet oszlopait írja le.

Ha egy nézetet a használatával WITH VIEW_METADATAhoz létre, az összes oszlopa , kivéve az időbélyeg-oszlopot , frissíthető, ha a nézet rendelkezik INSTEAD OF INSERT vagy INSTEAD OF UPDATE aktiválódik. Az frissíthető nézetekről további információt a Megjegyzések című témakörben talál.

Remarks

Nézet csak az aktuális adatbázisban hozható létre. A CREATE VIEW lekérdezési köteg első utasításának kell lennie. Egy nézet legfeljebb 1024 oszlopot tartalmazhat.

Nézeten keresztüli lekérdezéskor az adatbázismotor ellenőrzi, hogy az utasítás bármely pontján hivatkozott összes adatbázis-objektum létezik-e, és hogy azok érvényesek-e az utasítás kontextusában, és hogy az adatmódosítási utasítások nem sértik-e az adatintegritási szabályokat. A sikertelen ellenőrzés hibaüzenetet ad vissza. A sikeres ellenőrzés a műveletet egy műveletre fordítja le az alapul szolgáló táblán vagy táblákon.

Ha egy nézet egy elvetett táblától vagy nézettől függ, az adatbázismotor hibaüzenetet küld, amikor valaki megpróbálja használni a nézetet. Ha létrejön egy új tábla vagy nézet, és a táblaszerkezet nem változik az előző alaptábla helyett, a nézet ismét használhatóvá válik. Ha az új tábla- vagy nézetstruktúra megváltozik, a nézetet el kell dobni és újra létre kell hozni.

Ha a záradékkal SCHEMABINDING nem hoz létre nézetet, futtassa a sp_refreshview , amikor módosításokat végez a nézet alapjául szolgáló objektumokon, amelyek befolyásolják a nézet definícióját. Ellenkező esetben előfordulhat, hogy a nézet nem várt eredményeket eredményez, amikor lekérdezik.

A nézet létrehozásakor a rendszer a következő katalógusnézetekben tárolja a nézet adatait: sys.views, sys.columns és sys.sql_expression_dependencies. Az utasítás szövegét a CREATE VIEWsys.sql_modules katalógusnézetben tárolja a rendszer.

A numerikus vagy lebegőpontos kifejezésekkel definiált nézetben indexet használó lekérdezésnek olyan eredménye lehet, amely eltér egy hasonló lekérdezéstől, amely nem használja az indexet a nézetben. Ezt a különbséget okozhatják a kerekítési hibák a mögöttes INSERTDELETEtáblákon, illetve UPDATE műveletek során.

Az adatbázismotor menti a nézet beállításait SET QUOTED_IDENTIFIER , és SET ANSI_NULLS amikor létrejön egy nézet. Ezekkel az eredeti beállításokkal elemezheti a nézetet a nézet használatakor. Ezért a nézet elérésekor az ügyfél-munkamenet beállításai SET QUOTED_IDENTIFIERSET ANSI_NULLS nem befolyásolják a nézetdefiníciót.

Az Azure Synapse Analyticsben a nézetek nem támogatják a sémakötést. Ezért ha módosításokat végez az alapul szolgáló objektumokon, a nézetet el kell helyeznie és újra létre kell hoznia az alapul szolgáló metaadatok frissítéséhez. További információ: T-SQL-nézetek dedikált SQL-készlettel és kiszolgáló nélküli SQL-készlettel az Azure Synapse Analyticsben.

Az Azure Synapse Analyticsben az frissíthető nézetek, a DML-eseményindítók (típus AFTER vagy INSTEAD OF) és a particionált nézetek nem támogatottak. További információ: T-SQL-nézetek dedikált SQL-készlettel és kiszolgáló nélküli SQL-készlettel az Azure Synapse Analyticsben.

Az Azure Synapse Analyticsben a particionált nézetek nem támogatottak. További információ: T-SQL-nézetek dedikált SQL-készlettel és kiszolgáló nélküli SQL-készlettel az Azure Synapse Analyticsben.

A Fabric SQL-adatbázisban nézetek hozhatók létre, de nem tükrözhetők a Fabric OneLake-ben. További információ: Fabric SQL-adatbázis tükrözésének korlátozásai.

Frissíthető nézetek

Az alapul szolgáló alaptábla adatait egy nézeten keresztül módosíthatja, amennyiben az alábbi feltételek teljesülnek:

• Minden módosításnak, beleértve a UPDATE, INSERTés DELETE utasításokat, csak egy alaptábla oszlopaira kell hivatkoznia.

• A nézetben módosítandó oszlopoknak közvetlenül hivatkoznia kell a táblaoszlopok alapjául szolgáló adatokra. Az oszlopok nem származtathatók más módon, például a következő módon:

  • Összesítő függvény: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEVSTDEVP, VARés VARP.

  • Egy számítás. Az oszlop nem számítható ki olyan kifejezésből, amely más oszlopokat használ. Az UNION, UNION ALL, CROSSJOIN, EXCEPT és INTERSECT operátorok által létrehozott oszlopok számításnak minősülnek, és szintén nem frissíthetők.

• A módosítandó oszlopokat nem érintik GROUP BYa záradékok HAVINGvagy DISTINCT a záradékok.

• A TOP nem használható sehol a nézet select_statement a WITH CHECK OPTION záradékkal együtt.

Az előző korlátozások a nézet FROM záradékában szereplő összes albejárásra vonatkoznak, ugyanúgy, ahogy magára a nézetre is vonatkoznak. Az adatbázismotornak általában képesnek kell lennie egyértelműen nyomon követni a nézetdefiníció módosításait egy alaptáblára. További információ: Adatok módosítása nézeten keresztül.

Ha az előző korlátozások megakadályozzák, hogy közvetlenül egy nézeten keresztül módosítsa az adatokat, vegye figyelembe az alábbi lehetőségeket:

• TRIGGEREK HELYETT

  INSTEAD OF az eseményindítók létrehozhatók egy nézetben, hogy a nézet frissíthető legyen. Az INSTEAD OF eseményindító végrehajtása az eseményindítót definiáló adatmódosítási utasítás helyett történik. Ez az eseményindító lehetővé teszi, hogy a felhasználó meghatározza az adatmódosítási utasítás feldolgozásához végrehajtandó műveletek készletét. Ezért ha egy INSTEAD OF eseményindító létezik egy adott adatmódosítási utasítás (INSERTvagyUPDATE) nézetéhez, DELETEa megfelelő nézet frissíthető ezen az utasításon keresztül. Az eseményindítókkal kapcsolatos INSTEAD OF további információkért lásd a DML-eseményindítókat.

• Felosztott nézetek

  Ha a nézet particionált nézet, a nézet frissíthető, bizonyos korlátozásoktól függően. Szükség esetén az adatbázismotor megkülönbözteti a helyi particionált nézeteket, mint azokat a nézeteket, amelyekben az összes résztvevő tábla és nézet az SQL Server ugyanazon példányán található, és elosztott particionált nézeteket, mint azokat a nézeteket, amelyekben a nézetben lévő táblák legalább egyike egy másik vagy távoli kiszolgálón található.

Particionált nézetek

A particionált nézet olyan nézet, amelyet a UNION ALL tagtáblák azonos módon strukturáltak, de külön tárolnak, mint több tábla ugyanazon SQL Server-példányban vagy az SQL Server-kiszolgálók autonóm példányainak egy csoportjában, amelyet összevont adatbázis-kiszolgálóknak neveznek.

Note

Az adatok helyi és egy kiszolgáló közötti particionálásának előnyben részesített módszere particionált táblákon keresztül történik. További információ: particionált táblák és indexek.

Particionálási séma tervezésekor egyértelműnek kell lennie, hogy mely adatok tartoznak az egyes partíciókhoz. A tábla adatai Customers például három tagtáblában oszlanak el három kiszolgálóhelyen: Customers_33 be Server1, Customers_66 be Server2és Customers_99 be Server3.

A particionált nézet Server1 a következő módon van definiálva:

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

A nézet általában particionált nézetnek minősül, ha az a következő formában van:

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

Particionált nézetek létrehozásának feltételei

1. A kijelölés list

   • A nézetdefiníció oszloplistájában jelölje ki a tagtáblák összes oszlopát.

   • Győződjön meg arról, hogy az oszlopok select list azonos sorrendben azonos típusúak, beleértve a rendezéseket is. Nem elegendő, hogy az oszlopok implicit módon átalakítható típusok legyenek, ahogyan általában a UNION.

     Emellett legalább egy oszlopnak (például <col>) az összes választólistában ugyanabban a sorrendben kell megjelennie. Definiálja <col> úgy, hogy a tagtáblákban T1, ..., TnC1, ..., Cn a CHECK korlátozások meg vannak határozva <col>.

     A táblában C1 definiált korlátozásnak T1 a következő formában kell lennie:

     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 >  
     

   • A kényszereknek olyannak kell lenniük, hogy a megadott értékek <col> legfeljebb az egyik kényszernek C1, ..., Cn megfeleljenek, hogy a kényszerek különálló vagy nem összecsukott intervallumokat alkotnak. A particionálási oszlopnak nevezzük azt az oszlopot <col> , amelyen a különálló kényszerek definiálva vannak. A particionálási oszlopnak különböző nevei lehetnek az alapul szolgáló táblákban. A korlátozásoknak engedélyezett és megbízható állapotban kell lenniük ahhoz, hogy megfeleljenek a particionálási oszlop korábban említett feltételeinek. Ha a kényszerek le vannak tiltva, engedélyezze újra a kényszerellenőrzést a CHECK CONSTRAINT *constraint_name* beállítással ALTER TABLE, majd a WITH CHECK beállítással érvényesítheti őket.

     Az alábbi példák érvényes kényszerkészleteket mutatnak be:

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

   • Ugyanazt az oszlopot nem lehet többször használni a kijelölési listában.

2. Partíciós oszlop

   • A particionálási oszlop a tábla ELSŐDLEGES KULCSának része.

   • Nem lehet számított, identitás, alapértelmezett vagy időbélyegző oszlop.

   • Ha egy tagtábla ugyanazon oszlopán egynél több korlátozás van, az adatbázismotor figyelmen kívül hagyja az összes kényszert, és nem veszi figyelembe őket annak meghatározásakor, hogy a nézet particionált nézet-e. A particionált nézet feltételeinek teljesítéséhez győződjön meg arról, hogy a particionálási oszlopon csak egy particionálási korlátozás van.

   • A particionálási oszlop frissíthetősége nincs korlátozva.

3. Tagtáblák vagy mögöttes táblák T1, ..., Tn

   • A táblák lehetnek helyi táblák vagy más, SQL Servert futtató számítógépekről származó táblák, amelyekre négyrészes név vagy OPENDATASOURCE- vagy OPENROWSET-alapú név hivatkozik. Az OPENDATASOURCE és az OPENROWSET szintaxisa megadhat egy táblanevet, de átmenő lekérdezést nem. További információ: OPENDATASOURCE (Transact-SQL) és OPENROWSET (Transact-SQL).

     Ha egy vagy több tagtábla távoli, a nézetet elosztott particionált nézetnek nevezzük, és további feltételek érvényesek. Ezeket a szakasz későbbi részében ismertetjük.

   • Ugyanez a tábla nem jelenhet meg kétszer az utasítással UNION ALL kombinálandó táblák halmazában.

   • A tagtáblákban nem hozhatók létre indexek a tábla számított oszlopaiban.

   • A tagtáblákban az ELSŐDLEGES KULCS korlátozásai azonos számú oszlopra vannak állítva.

   • A nézetben lévő összes tagtábla rendelkezik ugyanazzal az ANSI-kitöltési beállítással. Ezt a beállításhoz használhatja a felhasználói beállítások vagy sp_configure a SET utasítás használatával.

A particionált nézetekben lévő adatok módosításának feltételei

A particionált nézetekben adatokat módosító utasításokra a következő korlátozások vonatkoznak:

• Az INSERT utasítás a nézetben lévő összes oszlop értékeit tartalmazza, még akkor is, ha az alapul szolgáló tagtáblákra DEFAULT kényszer érvényes ezekre az oszlopokra, vagy ha engedélyezik az NULL értékeket. A definíciókkal rendelkező DEFAULT tagtáblaoszlopok esetében az utasítások nem használhatják explicit módon a kulcsszót DEFAULT.

• A particionálási oszlopba beszúrt érték megfelel a mögöttes korlátozások legalább egyikének; ellenkező esetben a beszúrási művelet kényszersértéssel meghiúsul.

• UPDATE az utasítások nem adhatják meg a DEFAULT kulcsszót értékként a SET záradékban, még akkor sem, ha az oszlop DEFAULT értéke a megfelelő tagtáblában van meghatározva.

• A nézetben lévő olyan oszlopok, amelyek egy vagy több tagtábla identitásoszlopai, nem módosíthatók utasítással INSERT vagy UPDATE utasítással.

• Ha az egyik tagtábla időbélyegoszlopot tartalmaz, az adatok nem módosíthatók utasítással INSERT vagy UPDATE utasítással.

• Ha az egyik tagtábla eseményindítót vagy kényszert ON UPDATE CASCADE/SET NULL/SET DEFAULTON DELETE CASCADE/SET NULL/SET DEFAULT tartalmaz, a nézet nem módosítható.

• INSERT, UPDATEés DELETE a particionált nézeten végzett műveletek nem engedélyezettek, ha öncsatlakozás történik ugyanazzal a nézettel vagy az utasítás egyik tagtáblájával.

• Az adatok particionált nézetbe történő tömeges importálását nem támogatja vagy az bcp utasítások nem BULK INSERT támogatjákINSERT ... SELECT * FROM OPENROWSET(BULK...). Az INSERT utasítással azonban több sort is beszúrhat particionált nézetbe.

  Note

  A particionált nézet frissítéséhez a felhasználónak rendelkeznie INSERTkell a tagtáblákhoz tartozó engedélyekkel UPDATEés DELETE engedélyekkel.

Az elosztott particionált nézetek további feltételei

Elosztott particionált nézetek esetén (ha egy vagy több tagtábla távoli), a következő további feltételek érvényesek:

• Egy elosztott tranzakció indul el, amely garantálja az atomiságot a frissítés által érintett összes csomóponton.

• Állítsa be a XACT_ABORT SET beállítást, hogy ON az INSERT, UPDATEvagy DELETE az utasítások működjenek.

• A particionált nézetben hivatkozott kis méretű távoli táblákban lévő oszlopok pénzként vannak leképezve. Ezért a helyi táblák megfelelő oszlopainak (ugyanabban a sorrendben a kiválasztási listában) szintén pénz típusúnak kell lenniük.

• A 110-es és újabb adatbázis-kompatibilitási szint alatt a particionált nézetben hivatkozott , smalldatetime típusú távoli táblák oszlopai kisdátumként vannak leképezve. A helyi táblák megfelelő oszlopainak (ugyanabban a sorrendben a kiválasztási listában) kisdátumidőnek kell lenniük. Ez az SQL Server korábbi verzióinak viselkedésében bekövetkezett változás, amelyben a particionált nézetben hivatkozott smalldatetime típusú távoli táblák oszlopai dátumidőként vannak leképezve, a helyi táblák megfelelő oszlopainak pedig dátum/idő típusúnak kell lenniük. További információ: ALTER DATABASE kompatibilitási szintje (Transact-SQL).

• A particionált nézetben lévő csatolt kiszolgáló nem lehet visszacsatolt csatolt kiszolgáló. Ez egy csatolt kiszolgáló, amely az SQL Server ugyanazon példányára mutat.

A beállítás figyelmen kívül lesz hagyva az SET ROWCOUNT olyan műveleteknélINSERTUPDATE, DELETE amelyek frissíthető particionált nézeteket és távoli táblákat foglalnak magukban.

Ha a tagtáblák és a particionált nézetdefiníció érvényben van, az SQL Server lekérdezésoptimalizáló intelligens terveket hoz létre, amelyek lekérdezésekkel hatékonyan férnek hozzá a tagtáblák adataihoz. A CHECK kényszerdefiníciókkal a lekérdezésfeldolgozó leképezi a kulcsértékek eloszlását a tagtáblák között. Amikor egy felhasználó lekérdezést ad ki, a lekérdezésfeldolgozó összehasonlítja a leképezést a WHERE záradékban megadott értékekkel, és létrehoz egy végrehajtási tervet, amely minimális mennyiségű adatátvitelt biztosít a tagkiszolgálók között. Ezért ha egyes tagtáblák távoli kiszolgálókon találhatók, az SQL Server példánya feloldja az elosztott lekérdezéseket, hogy az átvitt elosztott adatok mennyisége minimális legyen.

A replikáció szempontjai

A replikációban részt vevő tagtáblák particionált nézeteinek létrehozásához az alábbi szempontokat kell figyelembe venni:

• Ha az alapul szolgáló táblák az előfizetések frissítésével történő egyesítésében vagy tranzakciós replikációjában vesznek részt, győződjön meg arról, hogy a uniqueidentifier oszlop is szerepel a kiválasztási listában.

  A particionált nézetben végrehajtott műveleteknek INSERT meg kell adniuk NEWID() a uniqueidentifier oszlop értékét. A uniqueidentifier oszlop frissítési műveleteinek értéket kell megadniuk NEWID() , mert az ALAPÉRTELMEZETT kulcsszó nem használható.

• A nézet használatával végrehajtott frissítések replikálása ugyanaz, mint amikor a táblákat két különböző adatbázisban replikálják: a táblákat különböző replikációs ügynökök szolgálják ki, és a frissítések sorrendje nem garantált.

Permissions

CREATE VIEW engedélyt igényel az adatbázisban, és alter engedélyt arra a sémára, amelyben a nézet létrejön.

Examples

Az alábbi példák az adatbázist vagy AdventureWorks2025 az adatbázist AdventureWorksDW2025 használják.

A. Nézet létrehozása a CREATE VIEW használatával

Az alábbi példa egy utasítással hoz létre nézetet SELECT . Az egyszerű nézet akkor hasznos, ha gyakran kérdezik le az oszlopok kombinációját. Az ebből a nézetből származó adatok az AdventureWorks2025 adatbázis és Person.Person táblázataiból származnakHumanResources.Employee. Az adatok az Adventure Works Cycles alkalmazottainak nevét és a felvétel dátumadatait biztosítják. A nézet létrehozható a munkahelyi évfordulók nyomon követéséért felelős személy számára, de anélkül, hogy hozzáférést adna a személynek a táblák összes adatához.

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. Használat TITKOSÍTÁSSAL

Az alábbi példa a beállítást használja, és megjeleníti a WITH ENCRYPTION számított oszlopokat, az átnevezett oszlopokat és a több oszlopot.

A következőkre vonatkozik: SQL Server 2008 (10.0.x) és újabb és 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  

C. A PIPA lehetőség használata

Az alábbi példa egy öt táblára hivatkozó nézetet dbo.SeattleOnly mutat be, amely lehetővé teszi, hogy az adatmódosítások csak a Seattle-ben élő alkalmazottakra vonatkozzanak.

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. Beépített függvények használata egy nézetben

Az alábbi példa egy beépített függvényt tartalmazó nézetdefiníciót mutat be. Függvények használatakor meg kell adnia a származtatott oszlop oszlopnevét.

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. Particionált adatok használata

Az alábbi példa a , , SUPPLY1SUPPLY2és SUPPLY3nevű SUPPLY4táblákat használja. Ezek a táblák négy különböző régióban található irodából származó szállítótábláknak felelnek meg.

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

Példák: Azure Synapse Analytics and Analytics Platform System (PDW)

F. Nézet létrehozása két tábla összekapcsolásával

Az alábbi példa egy nézetet hoz létre egy SELECT utasítással egy OUTER JOIN. Az illesztő lekérdezés eredményei kitöltik a nézetet.

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

Kapcsolódó tartalom

• ALTERNATÍV TÁBLÁZAT (Transact-SQL)
• ALTERNATÍV NÉZET (Transact-SQL)
• TÖRLÉS (Transact-SQL)
• DROP VIEW (Transact-SQL)
• BEHELYEZKEDÉS (Transact-SQL)
• Tárolt eljárás létrehozása
• 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)
• FRISSÍTÉS (Transact-SQL)
• ESEMÉNYADATOK (Transact-SQL)