Nejprve si připravíme tabulku se sloupcem ID a naplníme ji hodnotami 1 až 30000:

CREATE TABLE [dbo].[IdsTable]
   ( [Id] INT PRIMARY KEY )
GO

;WITH cte AS
(
	SELECT 1 ID
	UNION ALL
	SELECT ID + 1
	FROM [cte]
	WHERE cte.ID < 30000
)
INSERT [dbo].[IdsTable]
	SELECT *
	FROM cte
	OPTION(MAXRECURSION 0)

Vytvoříme tři testovací tabulky objednávek pro roky 2008 až 2010. Sloupec Id definujeme jako primární klíč a pomocí CHECK omezení určíme pro každou tabulku, že může obsahovat pouze hodnoty v uvedeném rozsahu:

CREATE TABLE [dbo].[Orders2008]
(	[Id] INT PRIMARY KEY
         CHECK ([Id] BETWEEN 1 AND 10000),
    [ProductId] INT,
    [Amount] INT )
GO

CREATE TABLE [dbo].[Orders2009]
(   [Id] INT PRIMARY KEY,
         CHECK ([Id] BETWEEN 10001 AND 20000),
    [ProductId] INT,
    [Amount] INT )
GO

CREATE TABLE [dbo].[Orders2010]
(   [Id] INT PRIMARY KEY,
         CHECK ([Id] BETWEEN 20001 AND 30000),
    [ProductId] INT,
    [Amount] INT )
GO

Tabulky naplníme testovacími daty. V tomu využijeme pomocnou tabulku IdsTable vytvořenou výše. Pomocí WHERE podmínky z ní vložíme do každé ze tří tabulek objednávek pouze hodnoty příslušného rozsahu:

INSERT [dbo].[Orders2008]
    SELECT [Id], [Id], ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) 
    FROM [dbo].[IdsTable]
    WHERE [Id] BETWEEN 1 AND 10000
GO

INSERT [dbo].[Orders2009]
    SELECT [Id], [Id], ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) 
    FROM [dbo].[IdsTable]
    WHERE [Id] BETWEEN 10001 AND 20000
GO

INSERT [dbo].[Orders2010]
    SELECT [Id], [Id], ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) 
    FROM [dbo].[IdsTable]
    WHERE [Id] BETWEEN 20001 AND 30000
GO

Nyní vytvoříme vlastní view, v němž všechny tři tabulky spojíme v jeden set pomocí UNION ALL operátoru.

CREATE VIEW [dbo].[v_Orders]
WITH SCHEMABINDING
AS
    SELECT [Id], [ProductId], [Amount] FROM [dbo].[Orders2008]
    UNION ALL
    SELECT [Id], [ProductId], [Amount] FROM [dbo].[Orders2009]
    UNION ALL
    SELECT [Id], [ProductId], [Amount] FROM [dbo].[Orders2010]
GO

Jak se chovají jednotlivé dotazy proti našemu pohledu si ukážeme na následujících příkladech.

Výběr všech dat z pohledu se chová podle očekávání: SQL Server provede scan všech tří tabulek a výsledek složí do jediného setu.

SELECT * FROM [dbo].[v_Orders]

Mnohem zajímavější situace nastává, pokud použijeme filtr podle sloupce, nad kterým jsme výše definovali CHECK omezení (partitioning column):

SELECT * FROM [dbo].[v_Orders] WHERE [Id] = 5000

Z exekučního plánu vidíme, že optimalizátor hledá data pouze v tabulce objednávek za rok 2009, protože námi hledaná hodnota 5000 spadá do rozsahu omezení, které jsme pro hodnoty v této tabulce definovali (1 až 10000)). Ostatní tabulky jsou z hledání vyloučeny logickou eliminací, neboť pouhým pohledem do metadat optimalizátor dokáže zjistit, že nad nimi definovaná CHECK omezení vylučují, aby se v nich hledaná hodnota mohla vykytovat.

Obdobným způsobem se chová i hledání podle kombinace různých hodnot. Opět jsou zahrnuty pouze tabulky, kde se hledaná hodnota může vyskytovat a vyloučeny ty, kde se hodnota nikdy vyskytnout nemůže:

SELECT * FROM [dbo].[v_Orders] WHERE [Id] IN (5000, 15000)

View lze využít i pro UPDATE, ale exekuční plán nás v tomto případě může překvapit, jak ukazuje následující příklad:

UPDATE [dbo].[v_Orders]
    SET [Amount] = 0
WHERE [Id] = 5000

Vidíme, že v exekučním plánu jsou zahrnuty všechny tři tabulky (Clustered Index Update). Důvodem je, že optimalizátor se snaží vygenerovat takový exekuční plán, který bude možné umístit do cache a využít později. Z toho důvodu musí být plán dostatečně robustní, aby platil i pro libovolné jiné vstupní hodnoty. Výše uvedený plán je tedy univerzální v tom smyslu, že bude použitelný i tehdy, pokud podmínka WHERE Id = X bude nabývat takových hodnot, že bude vždy proveden update v jiné základní tabulce, do jejíhož rozsahu omezení vstupní hodnota spadá.

Následující příklad nám ukazuje využití stejného univerzálního plánu na jiném rozsahu hodnot:

UPDATE [dbo].[v_Orders]
    SET [Amount] = 0
WHERE [Id] BETWEEN 21000 AND 29000

Pokud však přidáme do naší podmínky ještě sloupec Amount, vidíme, že exekuční plán již opět obsahuje část, která využívá logickou eliminaci (Clustered Index Seek):

UPDATE [dbo].[v_Orders]
    SET [Amount] = 0
WHERE [Id] BETWEEN 5000 AND 6000 AND [Amount] = 50

Ve všech výše uvedených příkladech obsahovala WHERE podmínka sloupec, který jsme použili pro rozdělení dat do jednotlivých tabulek podle hodnot (CHECK omezení). Pokud však tento sloupec z WHERE podmínky vynecháme, není optimalizátor schopen využít logickou eliminaci a určit tabulky, ve kterých se hledané hodnoty nemohou vyskytovat. Nemá pak jinou možnost, než prohledat všechny tabulky a ztrácíme tím výhodu eliminace, přesně jak vidíme níže:

SELECT * FROM [dbo].[v_Orders] WHERE [Amount] = 0

CREATE VIEW v_test AS
     SELECT *
     FROM OPENROWSET ('SQLOLEDB',  'SERVER=MyServer; Trusted_Connection=YES', 
                                    'SET FMTONLY OFF; EXEC sp_who')

-- Create sample table
CREATE TABLE dbo.SampleTable
(
    Id VARCHAR(10)
)
GO

-- Create views for testing
CREATE VIEW dbo.v_Test
AS
    SELECT Id FROM dbo.SampleTable
GO

CREATE VIEW dbo.v_Test2
AS
    SELECT Id FROM dbo.v_Test
GO

CREATE VIEW dbo.v_Test3
AS
    SELECT Id FROM dbo.v_Test2
GO

Let’s check metadata persisted at views creation:

SELECT 
    [o].[name], [t].[name] [TypeName], [c].[precision], [c].[scale]
FROM [sys].[columns] [c]
    INNER JOIN [sys].[objects] [o] ON [o].[object_id] = [c].[object_id]
	INNER JOIN [sys]. [t] ON [t].[system_type_id] = [c].[system_type_id] AND [t].[system_type_id] = [c].[system_type_id]
WHERE [o].[name] IN ('SampleTable', 'v_Test', 'v_Test2', 'v_Test3')
ORDER BY [o].[name]
GO

All views have it’s own metadata records in system tables saying that the underlying object column has VARCHAR data type. Le’ts go and change the data type in dbo.SampleTable from VARCHAR to INT and query metadata again.

ALTER TABLE dbo.SampleTable
    ALTER COLUMN Id INT
GO

Metadata are inconsistent now: Our base table has a column of INT datatype but all views on top of it are still holding the old information that it was VARCHAR previously. What to do now? Sure we can drop and recreate all views. But there is a better option: Let’s call the sp_refreshview system stored procedure and refresh the metadata of the v_Test view.

EXEC sp_refreshview 'v_Test'
GO

v_Test view has correct metadata now. But it’s obvious that we must do the same action for all remaining views.

EXEC sp_refreshview 'v_Test2'
GO

EXEC sp_refreshview 'v_Test3'
GO

Our database schema is consistent now. Congratulation. But isn’t it too much unpredictability and overhead to stay consistent? I can’t imagine application developers to take care of it when they are building tables. Most of the time they know zero about database metadata. So what are your options as DBA to prevent this to happen?

I see forced usage of the WITH SCHEMABINDING clause as the most reliable option. See more on how it works in this article. Yes, developers will complain all the time they have more work to do and when there is a huge structure of view maintenance of scripts can become complicated. But all that assures that zero errors related to outdated views metadata will occur by your customer. I will call this as a best practice and you can enforce it in your CI/CD pipeline.

Another option is that you will simply script refresh view on every view changed or run some generic script to refresh all views after each release. There is such a sample one:

DECLARE @Cnt INT = 0
DECLARE @Runs INT = 5 -- views will be updated up to this nested level
DECLARE @Stmt NVARCHAR(MAX) = ''

WHILE @Cnt < @Runs
BEGIN

	SELECT @Stmt = @Stmt + 'EXEC sp_refreshview ''' + s.[name] + '.' + v.[name] + ''';' + CHAR(13)
	FROM sys.[views] v
		INNER JOIN sys.[schemas] s ON [s].[schema_id] = [v].[schema_id]

	PRINT @Stmt

	EXEC (@Stmt)

	SET @Cnt = @Cnt + 1

END

It will load all views from the database and script EXEC sp_refreshview for each of them. It will repeat this until @Runs level is reached. This will handle the situation when views are nested and you should adjust it to your maximum known level of nesting. This is a brute-force solution but it works with minimum effort. Sure we can script it more in a more advanced way i.e. using sys.sql_expression_dependencies system view. I will try to write such a script for you later.