sql >> Databáze >  >> RDS >> Database

Základy tabulkových výrazů, Část 10 – Pohledy, SELECT * a změny DDL

V rámci série o tabulkových výrazech jsem minulý měsíc zahájil pokrytí pohledů. Konkrétně jsem začal pokrývat logické aspekty pohledů a porovnal jsem jejich návrh s odvozenými tabulkami a CTE. Tento měsíc budu pokračovat v pokrytí logických aspektů pohledů a zaměřím svou pozornost na změny SELECT * a DDL.

Kód, který budu používat v tomto článku, lze spustit v jakékoli databázi, ale v mých ukázkách budu používat TSQLV5 – stejnou ukázkovou databázi, kterou jsem použil v předchozích článcích. Skript, který vytváří a naplňuje TSQLV5, najdete zde a jeho ER diagram zde.

Použít SELECT * ve vnitřním dotazu pohledu je špatný nápad

V závěrečné části článku z minulého měsíce jsem položil otázku jako podnět k zamyšlení. Vysvětlil jsem, že dříve v této sérii jsem uvedl případ ve prospěch použití SELECT * ve vnitřních tabulkových výrazech používaných s odvozenými tabulkami a CTE. Pokud potřebujete osvěžit paměť, viz část 3 seriálu. Poté jsem vás požádal, abyste přemýšleli, zda by stejné doporučení bylo stále platné pro vnitřní tabulkový výraz používaný k definování pohledu. Možná už název této sekce byl spoiler, ale rovnou řeknu, že se zhlédnutími je to vlastně velmi špatný nápad.

Začnu pohledy, které nejsou definovány pomocí atributu SCHEMABINDING, který zabraňuje relevantním změnám DDL na závislých objektech, a pak vysvětlím, jak se věci změní, když použijete tento atribut.

Přejdu rovnou k příkladu, protože to bude nejjednodušší způsob, jak prezentovat můj argument.

Pomocí následujícího kódu vytvořte tabulku s názvem dbo.T1 a zobrazení s názvem dbo.V1 na základě dotazu s SELECT * proti tabulce:

POUŽÍVEJTE TSQLV5; ZAPNOUT ZOBRAZENÍ, POKUD EXISTUJE dbo.V1;PUSTIT TABULKU, POKUD EXISTUJE dbo.T1;GO CREATE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMÁRNÍ KLÍČ, intcol INT NOT NULL, charcol VARNULL(10) NOT; INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO CREATE OR ALTER VIEW dbo.V1AS SELECT * FROM dbo.T1;GO

Všimněte si, že tabulka má aktuálně sloupce keycol, intcol a charcol.

K dotazu na zobrazení použijte následující kód:

SELECT * FROM dbo.V1;

Získáte následující výstup:

keycol intcol charcol----------- ----------- ----------1 10 A2 20 B

Není zde nic zvláštního.

Když vytvoříte pohled, SQL Server zaznamená informace o metadatech v řadě objektů katalogu. Zaznamenává některé obecné informace, na které se můžete dotazovat přes sys.views, definici pohledu, na kterou se můžete dotazovat přes sys.sql_modules, informace o sloupcích, na které se můžete dotazovat přes sys.columns, a další informace jsou dostupné prostřednictvím dalších objektů. Pro naši diskusi je také důležité, že SQL Server vám umožňuje řídit přístupová oprávnění vůči pohledům. Na co vás chci upozornit při použití SELECT * ve výrazu vnitřní tabulky pohledu, je to, co se může stát, když jsou změny DDL aplikovány na základní závislé objekty.

Pomocí následujícího kódu vytvořte uživatele s názvem user1 a udělte uživateli oprávnění k výběru sloupců keycol a intcol ze zobrazení, ale ne charcol:

DROP USER IF EXISTS user1; CREATE USER user1 BEZ PŘIHLÁŠENÍ; GRANT SELECT ON dbo.V1(keycol, intcol) TO user1;

V tomto okamžiku si prohlédněme některá zaznamenaná metadata související s naším pohledem. Pomocí následujícího kódu vraťte položku představující zobrazení ze sys.views:

SELECT SCHEMA_NAME(schema_id) AS schemaname, name, object_id, type_descFROM sys.viewsWHERE object_id =OBJECT_ID(N'dbo.V1');

Tento kód generuje následující výstup:

název schématu object_id type_desc----------- ----- ----------- -----------dbo V1 130099504 VIEW 

Pro získání definice pohledu ze sys.modules použijte následující kód:

SELECT definice FROM sys.sql_modulesWHERE object_id =OBJECT_ID(N'dbo.V1');

Další možností je použít funkci OBJECT_DEFINITION takto:

SELECT OBJECT_DEFINITION(OBJECT_ID(N'dbo.V1'));

Získáte následující výstup:

CREATE VIEW dbo.V1AS SELECT * FROM dbo.T1;

K dotazu na definice sloupců zobrazení z sys.columns použijte následující kód:

SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');

Podle očekávání získáte informace o třech sloupcích keycol, intcol a charcol zobrazení:

název_sloupce id_sloupce data_type------------ ----------- ----------keycol 1 intintcol 2 intcharcol 3 varchar

Sledujte ID sloupců (řadové pozice), které jsou ke sloupcům přidruženy.

Podobné informace můžete získat dotazem na standardní zobrazení informačního schématu INFORMATION_SCHEMA.COLUMNS, například takto:

SELECT COLUMN_NAME, ORDINAL_POSITION, DATA_TYPEFROM INFORMATION_SCHEMA.COLUMNSWHERE TABLE_SCHEMA =N'dbo' AND TABLE_NAME =N'V1';

Chcete-li získat informace o závislosti zobrazení (objekty, na které odkazuje), můžete se zeptat na sys.dm_sql_referenced_entities, například takto:

SELECT OBJECT_NAME(referenced_id) AS referenced_object, referenced_minor_id, COL_NAME(referenced_id, referenced_minor_id) AS column_nameFROM sys.dm_sql_referenced_entities(N'dbo.V1', N'OBJECT');

Závislost najdete na tabulce T1 a na jejích třech sloupcích:

referenced_object referenced_minor_id column_name------------------ ------------------- ------- ----T1 0 NULLT1 1 keycolT1 2 intcolT1 3 charcol

Jak jste pravděpodobně uhodli, hodnota reference_minor_id pro sloupce je ID sloupce, které jste viděli dříve.

Pokud chcete získat oprávnění uživatele1 proti V1, můžete se zeptat na sys.database_permissions takto:

SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, license_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id (N'user_id =USER_ID) před> 

Tento kód generuje následující výstup, který potvrzuje, že uživatel1 má skutečně oprávnění k výběru pouze proti keycol a intcol, ale ne proti charcol:

referencovaný_objekt minor_id název_sloupce název_oprávnění------------------ ----------- ------------ -- --------------V1 1 klíčový sloupec SELECTV1 2 mezinápis SELECT

Opět platí, že hodnota minor_id je ID sloupce, které jste viděli dříve. Náš uživatel, uživatel1, má oprávnění ke sloupcům, jejichž ID jsou 1 a 2.

Dále spusťte následující kód pro zosobnění uživatele1 a pokuste se dotazovat všechny sloupce V1:

PROVEĎ JAKO UŽIVATEL =N'user1'; SELECT * FROM dbo.V1;

Jak byste očekávali, zobrazí se chyba oprávnění kvůli nedostatku oprávnění k dotazu charcol:

Zpráva 230, Úroveň 14, Stav 1, Řádek 141
Oprávnění SELECT bylo odepřeno pro sloupec 'charcol' objektu 'V1', databáze 'TSQLV5', schéma 'dbo'.

Zkuste zadat dotaz pouze keycol a intcol:

SELECT keycol, intcol FROM dbo.V1;

Tentokrát se dotaz spustí úspěšně a vygeneruje následující výstup:

keycol intcol----------- -----------1 102 20

Zatím žádné překvapení.

Chcete-li se vrátit k původnímu uživateli, spusťte následující kód:

VRÁTIT;

Nyní použijeme několik strukturálních změn na podkladovou tabulku dbo.T1. Spuštěním následujícího kódu nejprve přidejte dva sloupce nazvané datecol a binarycol a poté vypusťte sloupec intcol:

ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233); ALTER TABLE dbo.T1 DROP COLUMN intcol;

SQL Server neodmítl strukturální změny sloupců, na které odkazuje zobrazení, protože zobrazení nebylo vytvořeno s atributem SCHEMABINDING. Teď k úlovku. V tomto okamžiku SQL Server ještě neobnovil informace o metadatech zobrazení v různých objektech katalogu.

K dotazu na zobrazení použijte následující kód, stále s vaším původním uživatelem (zatím ne user1):

SELECT * FROM dbo.V1;

Získáte následující výstup:

keycol intcol charcol----------- ---------- ----------1 A 9999-12-312 B 9999-12-31 

Všimněte si, že intcol ve skutečnosti vrací obsah charcol a charcol vrací obsah datecol. Pamatujte, že v tabulce již není žádný intcol, ale je tam datecol. Také nedostanete zpět nový sloupec binarycol.

Chcete-li se pokusit zjistit, co se děje, použijte následující kód k dotazu na metadata sloupce zobrazení:

SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');

Tento kód generuje následující výstup:

název_sloupce id_sloupce data_type------------ ----------- ----------keycol 1 intintcol 2 intcharcol 3 varchar

Jak vidíte, metadata zobrazení stále nejsou obnovena. Můžete vidět intcol jako sloupec ID 2 a charcol jako sloupec ID 3. V praxi již intcol neexistuje, charcol má být sloupec 2 a datecol má být sloupec 3.

Pojďme zkontrolovat, zda nedošlo k nějaké změně s informacemi o oprávnění:

SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, license_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id (N'user_id =USER_ID) před> 

Získáte následující výstup:

referencovaný_objekt minor_id název_sloupce název_oprávnění------------------ ----------- ------------ -- --------------V1 1 klíčový sloupec SELECTV1 2 mezinápis SELECT

Informace o oprávnění ukazují, že uživatel1 má oprávnění ke sloupcům 1 a 2 v zobrazení. I když si metadata myslí, že sloupec 2 se nazývá intcol, ve skutečnosti je v praxi mapován na znak charcol v T1. To je nebezpečné, protože uživatel 1 nemá mít přístup k charcol. Co když v reálném životě tento sloupec obsahuje citlivé informace, jako jsou hesla.

Pojďme znovu zosobnit uživatele1 a dotazovat se na všechny sloupce zobrazení:

EXECUTE AS USER ='uživatel1'; SELECT * FROM dbo.V1;

Zobrazí se chyba oprávnění, která říká, že nemáte přístup ke znaku charcol:

Zpráva 230, Úroveň 14, Stav 1, Řádek 211
Oprávnění SELECT bylo odepřeno pro sloupec 'charcol' objektu 'V1', databáze 'TSQLV5', schéma 'dbo'.

Podívejte se však, co se stane, když výslovně požádáte o keycol a intcol:

SELECT keycol, intcol FROM dbo.V1;

Získáte následující výstup:

keycol intcol----------- ----------1 A2 B

Tento dotaz uspěje, pouze vrátí obsah charcol pod intcol. Náš uživatel, uživatel1, nemá mít k těmto informacím přístup. Jejda!

V tomto okamžiku se vraťte zpět k původnímu uživateli spuštěním následujícího kódu:

VRÁTIT;

Obnovit modul SQL

Jasně vidíte, že použití SELECT * ve výrazu vnitřní tabulky pohledu je špatný nápad. Ale není to jen to. Obecně je vhodné aktualizovat metadata pohledu po každé změně DDL na odkazované objekty a sloupce. Můžete tak učinit pomocí sp_refreshview nebo obecnějšího sp_refreshmodule, například takto:

EXEC sys.sp_refreshsqlmodule N'dbo.V1';

Nyní, když byla jeho metadata obnovena, znovu se dotazujte na zobrazení:

SELECT * FROM dbo.V1;

Tentokrát získáte očekávaný výstup:

keycol charcol datecol binarycol----------- ---------- ---------- ---------1 A 9999 -12-31 0x1122332 B 9999-12-31 0x112233

Sloupec charcol je pojmenován správně a zobrazuje správná data; nevidíte intcol a vidíte nové sloupce datecol a binarycol.

Dotaz na metadata sloupce zobrazení:

SELECT name AS column_name, column_id, TYPE_NAME(system_type_id) AS data_typeFROM sys.columnsWHERE object_id =OBJECT_ID(N'dbo.V1');

Výstup nyní zobrazuje správné informace o metadatech sloupců:

column_name column_id data_type------------ ----------- ----------keycol 1 intcharcol 2 varchardatecol 3 datebinarycol 4 varbinary 

Dotaz na oprávnění uživatele1 k zobrazení:

SELECT OBJECT_NAME(major_id) AS referenced_object, minor_id, COL_NAME(major_id, minor_id) AS column_name, license_nameFROM sys.database_permissionsWHERE major_id =OBJECT_ID(N'dbo.V1') AND grantee_principal_id (N'user_id =USER_ID) před> 

Získáte následující výstup:

referencovaný_objekt minor_id název_sloupce název_oprávnění------------------ ----------- ------------ -- --------------V1 1 klíčový sloupec SELECT

Informace o povolení jsou nyní správné. Náš uživatel, uživatel1, má oprávnění pouze k výběru keycol a informace o oprávněních pro intcol byly odstraněny.

Abyste se ujistili, že je vše v pořádku, otestujte to tak, že se budete vydávat za uživatele1 a dotazovat se na zobrazení:

EXECUTE AS USER ='uživatel1'; SELECT * FROM dbo.V1;

Dostanete dvě chyby oprávnění kvůli nedostatku oprávnění pro datecol a binarycol:

Msg 230, Level 14, State 1, Line 281
Oprávnění SELECT bylo odepřeno pro sloupec 'datecol' objektu 'V1', databáze 'TSQLV5', schéma 'dbo'.

Zpráva 230, Úroveň 14, Stav 1, Řádek 281
Oprávnění SELECT bylo odepřeno pro sloupec 'binarycol' objektu 'V1', databáze 'TSQLV5', schéma 'dbo'.

Zkuste se zeptat keycol a intcol:

SELECT keycol, intcol FROM dbo.V1;

Tentokrát chyba správně říká, že neexistuje žádný sloupec s názvem intcol:

Zpráva 207, úroveň 16, stát 1, linka 279

Neplatný název sloupce 'intcol'.

Dotaz pouze intcol:

SELECT keycol FROM dbo.V1;

Tento dotaz běží úspěšně a generuje následující výstup:

keycol-----------12

V tomto okamžiku se vraťte zpět k původnímu uživateli spuštěním následujícího kódu:

VRÁTIT;

Stačí se vyhnout SELECT * a používat explicitní názvy sloupců?

Pokud se budete řídit praxí, která říká, že ve výrazu vnitřní tabulky pohledu není SELECT *, stačilo by to, abyste se nedostali do problémů? No, uvidíme…

K opětovnému vytvoření tabulky a zobrazení použijte následující kód, tentokrát pouze explicitně uveďte sloupce ve vnitřním dotazu zobrazení:

VYHNOUT ZOBRAZENÍ, POKUD EXISTUJE dbo.V1;PUSTIT TABULKU, POKUD EXISTUJE dbo.T1;GO CREATE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMAR KEY, intcol INT NOT NULL, charcol VARCHAR(10)); INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO CREATE OR ALTER VIEW dbo.V1AS SELECT keycol, intcol, charcol FROM dbo.T1;GO

Dotaz na zobrazení:

SELECT * FROM dbo.V1;

Získáte následující výstup:

keycol intcol charcol----------- ----------- ----------1 10 A2 20 B

Opět udělte uživateli1 oprávnění k výběru keycol a intcol:

GRANT SELECT ON dbo.V1(keycol, intcol) TO user1;

Dále použijte stejné strukturální změny jako předtím:

ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233); ALTER TABLE dbo.T1 DROP COLUMN intcol;

Všimněte si, že SQL Server přijal tyto změny, i když má zobrazení explicitní odkaz na intcol. Opět je to proto, že pohled byl vytvořen bez možnosti SCHEMABINDING.

Dotaz na zobrazení:

SELECT * FROM dbo.V1;

V tomto okamžiku SQL Server generuje následující chybu:

Msg 207, Level 16, State 1, Procedure V1, Line 5 [Batch Start Line 344]
Neplatný název sloupce 'intcol'.

Msg 4413, Level 16, State 1, Line 345
Nelze použít zobrazení nebo funkci 'dbo.V1' kvůli chybám vazby.

SQL Server se pokusil vyřešit odkaz intcol v pohledu a samozřejmě neúspěšně.

Ale co když byl váš původní plán vypustit intcol a později jej přidat zpět? Pomocí následujícího kódu jej přidejte zpět a poté se dotazujte na zobrazení:

ALTER TABLE dbo.T1 ADD intcol INT NOT NULL DEFAULT(0); SELECT * FROM dbo.V1;

Tento kód generuje následující výstup:

keycol intcol charcol----------- ----------- ----------1 0 A2 0 B

Výsledek se zdá správný.

Co takhle dotazovat se na pohled jako uživatel1? Zkusme to:

EXECUTE AS USER ='user1';SELECT * FROM dbo.V1;

Při dotazování na všechny sloupce se zobrazí očekávaná chyba kvůli nedostatku oprávnění proti charcol:

Zpráva 230, úroveň 14, stav 1, řádek 367
Oprávnění SELECT bylo odepřeno ve sloupci 'charcol' objektu 'V1', databáze 'TSQLV5', schéma 'dbo'.

Explicitně dotazujte keycol a intcol:

SELECT keycol, intcol FROM dbo.V1;

Získáte následující výstup:

keycol intcol----------- -----------1 02 0

Zdá se, že je vše v pořádku díky tomu, že jste nepoužili SELECT * ve vnitřním dotazu pohledu, i když jste neobnovili metadata pohledu. Přesto by mohlo být dobrým zvykem aktualizovat metadata zobrazení po změnách DDL na odkazované objekty a sloupce, abyste byli na bezpečné straně.

V tomto okamžiku se vraťte zpět k původnímu uživateli spuštěním následujícího kódu:

VRÁTIT;

SCHEMABINDING

Použitím atributu zobrazení SCHEMABINDING si můžete ušetřit spoustu výše zmíněných problémů. Jedním z klíčů, jak se vyhnout potížím, které jste viděli dříve, je nepoužívat SELECT * ve vnitřním dotazu pohledu. Existuje však také problém se strukturálními změnami u závislých objektů, jako je vypuštění odkazovaných sloupců, které mohou stále vést k chybám při dotazování na pohled. Pomocí atributu zobrazení SCHEMABINDING nebudete moci použít SELECT * ve vnitřním dotazu. Kromě toho SQL Server odmítne pokusy aplikovat příslušné změny DDL na závislé objekty a sloupce. Relevantně mám na mysli změny, jako je odstranění odkazované tabulky nebo sloupce. Přidání sloupce do odkazované tabulky samozřejmě není problém, takže SCHEMABINDING takové změně nebrání.

Chcete-li to demonstrovat, použijte následující kód k opětovnému vytvoření tabulky a pohledu s SCHEMABINDING v definici pohledu:

VYHNOUT ZOBRAZENÍ, POKUD EXISTUJE dbo.V1;PUSTIT TABULKU, POKUD EXISTUJE dbo.T1;GO CREATE TABLE dbo.T1( keycol INT NOT NULL IDENTITY CONSTRAINT PK_T1 PRIMAR KEY, intcol INT NOT NULL, charcol VARCHAR(10)); INSERT INTO dbo.T1(intcol, charcol) VALUES (10, 'A'), (20, 'B');GO VYTVOŘIT NEBO ZMĚNIT ZOBRAZENÍ dbo.V1 S VÝBĚREM SCHEMABINDINGAS * Z dbo.T1;GO

Zobrazí se chyba:

Zpráva 1054, Úroveň 15, Stav 6, Postup V1, Řádek 5 [Řádek zahájení dávky 387]
Syntaxe '*' není povolena v objektech vázaných na schéma.

Při použití SCHEMABINDING není povoleno používat SELECT * ve výrazu vnitřní tabulky pohledu.

Zkuste zobrazení vytvořit znovu, ale tentokrát s explicitním seznamem sloupců:

VYTVOŘTE NEBO ZMĚŇTE ZOBRAZENÍ dbo.V1 POMOCÍ SCHEMABINDINGAS SELECT keycol, intcol, charcol Z dbo.T1;GO

Tentokrát je pohled vytvořen úspěšně.

Udělte uživateli 1 oprávnění pro keycol a intcol:

GRANT SELECT ON dbo.V1(keycol, intcol) TO user1;

Dále se pokuste aplikovat strukturální změny na tabulku. Nejprve přidejte několik sloupců:

ALTER TABLE dbo.T1 ADD datecol DATE NOT NULL DEFAULT('99991231'), binarycol VARBINARY(3) NOT NULL DEFAULT(0x112233);

Přidání sloupců není problém, protože nemohou být součástí existujících zobrazení vázaných na schéma, takže tento kód se úspěšně dokončí.

Pokuste se vypustit intcol sloupce:

ALTER TABLE dbo.T1 DROP COLUMN intcol;

Zobrazí se následující chyba:

Msg 5074, Level 16, State 1, Line 418
Objekt 'V1' je závislý na sloupci 'intcol'.

Msg 4922, Level 16, State 9, Line 418
ALTER TABLE DROP COLUMN intcol se nezdařilo, protože k tomuto sloupci má přístup jeden nebo více objektů.

Odstraňování nebo pozměňování odkazovaných sloupců je zakázáno, pokud existují objekty vázané na schéma.

Pokud stále potřebujete zrušit intcol, budete muset nejprve zrušit odkazující pohled vázaný na schéma, použít změnu a poté znovu vytvořit pohled a znovu přiřadit oprávnění, například takto:

PŘEDEJTE ZOBRAZENÍ, POKUD EXISTUJE dbo.V1;PŘEJÍT ZMĚNIT TABULKU dbo.T1 PŘEHNOUT SLOUPEK intcol;PŘEJÍT VYTVOŘIT NEBO ZMĚNIT ZOBRAZENÍ dbo.V1 POMOCÍ SCHEMABINDINGAS SELECT keycol, charcol, datecol, binarycol Z dbo.Tbo SELECT ONGO V1(klíčová kolonka, datumová kolonka, binární kolonka) TO user1;GO

V tuto chvíli samozřejmě není potřeba obnovovat definici pohledu, protože jste ji vytvořili znovu.

Nyní, když jste dokončili testování, spusťte následující kód pro vyčištění:

PUSTIT ZOBRAZENÍ, POKUD EXISTUJE dbo.V1;PUSTIT TABULKU, POKUD EXISTUJE dbo.T1;PUSTIT UŽIVATELE, POKUD EXISTUJE uživatel1;

Shrnutí

Použití SELECT * ve výrazu vnitřní tabulky pohledu je velmi špatný nápad. Po použití strukturálních změn na odkazované objekty můžete získat nesprávné názvy sloupců a dokonce umožnit uživatelům přístup k datům, ke kterým nemají mít přístup. Je důležité uvést explicitně názvy odkazovaných sloupců.

Pomocí SCHEMABINDING v definici pohledu jste nuceni explicitně uvést názvy sloupců a relevantní strukturální změny závislých objektů jsou SQL Serverem odmítnuty. Proto se může zdát, že vytváření pohledů pomocí SCHEMBINDING je vždy dobrý nápad. U této možnosti však existuje upozornění. Jak jste viděli, použití strukturálních změn na odkazované objekty při použití SCHEMBINDING se stává delším a propracovanějším procesem. Zejména to může být problém v systémech, které musí mít velmi vysokou dostupnost. Představte si, že potřebujete změnit sloupec definovaný jako VARCHAR(50) na VARCHAR(60). To není povolená změna, pokud existuje pohled definovaný s SCHEMABINDING odkazujícím na tento sloupec. Důsledky vypuštění hromady odkazujících pohledů, na které by mohly odkazovat jiné pohledy atd., by mohly být pro systém problematické. Stručně řečeno, pro společnosti není vždy tak triviální přijmout politiku, která říká, že SCHEMABINDING by se měl používat ve všech objektech, které jej podporují. Přijetí zásady nepoužívat SELECT * ve vnitřních dotazech pohledů by však mělo být jednodušší.

Ohledně zobrazení je toho k prozkoumání mnohem víc. Pokračování příští měsíc…


  1. Klauzule ORDER BY je neplatná v pohledech, vložených funkcích, odvozených tabulkách, poddotazech a běžných tabulkových výrazech.

  2. Aktualizujte více tabulek v SQL Server pomocí INNER JOIN

  3. Zachovejte zalomení řádků z TextArea při zápisu do MySQL

  4. Správa rolí a stavů v systému