Let’s prepare two tables we will play with. One of them will be [dbo].[TargetTable] where data will be inserted from the second table [dbo].[SourceTable].

DROP TABLE IF EXISTS [dbo].[TargetTable]
DROP TABLE IF EXISTS [dbo].[SourceTable]
GO

CREATE TABLE [dbo].[TargetTable] (
	[ID] INT NOT NULL,
	[Value] NVARCHAR(100)
)
GO

CREATE TABLE [dbo].[SourceTable] (
	[ID] INT NOT NULL,
	[Value] NVARCHAR(100),
	[OtherValue] NVARCHAR(100)
)
GO

INSERT INTO [dbo].[SourceTable]
	( [ID], [Value], [OtherValue] )
	VALUES 
	(1, 'Val1', 'OthVal1' ),
	(2, 'Val2', 'OthVal2' ),
	(3, 'Val3', 'OthVal3' )
GO

Once everything is prepared we can try the following statement to insert data from the source table to the target table. We would like also to output some columns we will use for review or processing later (if we will use table or table variable as OUTPUT target):

INSERT INTO [dbo].[TargetTable]
	( [ID],	[Value] )
		OUTPUT [Inserted].[ID], [Inserted].[Value], [src].[OtherValue]
	SELECT 
		[src].[ID], [src].[Value]
	FROM [dbo].[SourceTable] [src]
GO

The statement has failed because of the column [src].[OtherValue] isn’t one of the columns inserted into the target table and therefore it isn’t allowed to be referenced in the OUTPUT clause.

But what should be done if we really need this column in the output? We can simply get it when MERGE will be used instead of INSERT:

MERGE INTO [dbo].[TargetTable] [trg]
USING ( SELECT [ID], [Value], [OtherValue]
		FROM [dbo].[SourceTable]
	  ) AS [src] ON 1 = 0
WHEN NOT MATCHED THEN
	INSERT ( [ID],[Value] )
	VALUES ([src].[ID], [src].[Value])
		OUTPUT [Inserted].[ID], [Inserted].[Value], [src].[OtherValue];
GO

MERGE is much flexible to be used together with the OUTPUT clause and is suitable for a lot of special scenarios like this one. INSERT still have its place. Using MERGE everywhere instead of INSERTED isn’t a good idea. People reading our code will be confused and MERGE has still a lot of issues and hidden drawbacks unresolved.

Syntax:

SELECT *
	INTO dbo.SampleTable_Copy
		ON OtherFilegoup
FROM dbo.SampleTable
GO

More detail can be found in MSDN or simple demonstration at mssqltips.com.

Jako první si ukážeme použití TVC s příkazem INSERT, abychom si naplnili naši testovací tabulku:

CREATE TABLE dbo.SampleTable
(
    Id INT NOT NULL,
    Val VARCHAR(20) NULL DEFAULT ('X')
)
GO

INSERT INTO dbo.SampleTable
    VALUES (1, 'A'), (2, 'B'), (3, 'C')
GO

SELECT * FROM dbo.SampleTable
GO

Vidíme, že v rámci jednoho DML příkazu jsem vytvořili tři virtuální řádky, které se nakonec vložili do cílové tabulky.

Kromě explicitního zadání hodnot můžeme využít i DEFAULT pro vložení výchozí hodnoty do sloupce, případně NULL, není-li hodnota známa:

INSERT INTO dbo.SampleTable
    VALUES (4, 'A'), (5, DEFAULT), (6, NULL)
GO

Že pomocí TVC vytváří skutečně “virtuální tabulku” v rámci daného SQL příkazu snad nejlépe uvidíme, použijeme-li TVC ve FROM jako by se jednalo i jakoukoliv jinou tabulku:

SELECT * 
FROM (VALUES (1, 'A'), 
             (2, 'B'), 
             (3, 'C')
      ) a (Id, Val)
GO

A nebo ještě lépe, můžeme si pro větší názornost několik TVC mezi sebou propojit:

SELECT * 
FROM (VALUES (1, 'A'), 
             (2, 'B'), 
             (3, 'C')
      ) a (Id, Val)
    INNER JOIN (VALUES (1, 'A'), 
                       (2, 'B'), 
                       (3, 'C')
                ) b (Id, Val) ON a.Id = b.Id
GO

Opravdovou lahůdkou je potom možnost tvořit jednotlivé hodnoty řádku pomocí klasického příkazu SELECT:

SELECT * 
FROM (VALUES (1, 'A'), 
             (2, (SELECT 'B')),
             (3, (SELECT TOP(1) LEFT(NAME, 20) FROM sys.objects WHERE NAME LIKE '%%'))
     ) a (Id, Val)
GO

TVC je také možné libovolně vzájemně zanořovat:

SELECT * 
FROM (VALUES (1, 
              (SELECT Val FROM (VALUES ('A')) b (Val))
              )
      ) a (Id, Val)
GO

Stejně tak můžeme TVC dotazovat jako klasikou tabulku v různých kombinacích SELECT příkazu:

SELECT 
    (SELECT TOP(1) Id FROM (VALUES (1, 'A'), (2, 'B'), (3, 'C')) a (Id, Val) ORDER BY Val DESC) Id
FROM (SELECT 1 a) a
GO

Co ovšem již udělat nemůže je, pokusit se použít TVC s jinými DML příkazy než INSERT, tedy s UPDATE nebo DELETE, případně na <target table> straně příkazu MERGE:

UPDATE a
	SET Id = 5
--SELECT * 
FROM (VALUES (1, 'A'), 
             (2, 'B'), 
             (3, 'C')
      ) a (Id, Val)
GO

To vše samozřejmě platí pouze tehdy, pokoušíme-li se měnit data vytvořená pomocí TVC. Využít TVC následujícím způsobem možné je, neboť zde je součástí SELECT příkazu:

UPDATE st
	SET Val = 'UPD_' + CAST(a.Id AS VARCHAR(10))
--SELECT *
FROM dbo.SampleTable st
	INNER JOIN (VALUES(1), (2)) a (Id) on st.ID = a.ID
GO

Pokud jsem hovořili o použití TVC s příkazem MERGE na místě <source table>, vypadá náš příklad takto:

MERGE INTO dbo.SampleTable trg
USING 
	(VALUES
		(3, 'MRG'),
		(4, 'NEW')
	) AS src (Id, Val)
	ON trg.Id = src.Id
WHEN NOT MATCHED THEN
	INSERT (Id, Val)
	VALUES (src.Id, src.Val)
WHEN MATCHED THEN UPDATE 
	SET trg.Val = src.Val;
GO

Na co nesmíme zapomenout při využít TVC ve FROM jsou pravidla pro pojmenování sloupců u odvozených tabulek: První příkaz skončí s chybou, protože jsem zapomněli pojmenovat sloupce. Jak to napravit ukazuje druhý příkaz:

SELECT * FROM (VALUES (1, 'A')) a
GO

SELECT * FROM (VALUES (1, 'A')) a (Id, Val)
GO

Pozor je třeba dát i na to, že DEFAULT můžeme použít pouze tehdy, vkládáme-li data do tabulky v rámci INSERT příkazu, nikoliv v pouhém SELECTu:

SELECT * FROM (VALUES (1, DEFAULT)) a (Id, Val)
GO

Jednoduchá ukázka jak na to syntakticky je zde:

SELECT *
FROM dbo.TestTable
WHERE Id = @Id AND
      (
       CASE
            WHEN @Type = 'D' AND Cislo = @Id2 THEN 1
            WHEN @Type = 'L' AND Cislo = @Id2 THEN 1
            ELSE 0
       END
      ) = 1

Více CTE spojíme k sobě jednoduše pomocí čárky, kterou je od sebe oddělíme dvě nebo více definic. Klauzule WITH se zapisuje pouze u první definice. Každá další definice může může přistupovat k datovému setu vytvořenému v definici předcházejí. Reference v opačném směru nejsou možné.

Celou funkcionalitu si ukážeme na následujícím jednoduchém skriptu:

WITH 
CTE1 (N) 
AS (
     SELECT 1 
     UNION ALL
     SELECT 2
   ),
CTE2 (N) 
AS (
      SELECT c1.N 
      FROM CTE1 c1 
		CROSS JOIN CTE1 c2 
    )
SELECT * 
FROM CTE2
    INNER JOIN CTE1 ON CTE1.N = CTE2.N

V první kroku jsme vytvořili set CTE1, který obsahuje dva řádky s hodnotami 1 a 2, spojenými pomocí UNION ALL. Definici jsme uzavřeli závorkou a čárkou, za níž jsme vytvořili definici CTE2, která již může používat předtím vytvořený set CTE1. V posledním kroku jsme v SELECT dotazu vypsali řádky ze setu CTE2, ale stejně tak dobře můžeme referencovat kterýkoliv výše definovaný set, jak v našm příkladu ukazuje INNER JOIN na CTE1.

Ačkoliv syntaktický zápis svádí k tomu, abychom předpokládali, že SQL Server uvažuje logicky a nejdříve vykoná dotaz pro CTE1, poté nad výsledkem dotaz pro CTE2, atd., ve většině případů tomu tak není a můžeme být opravdu překvapeni, co optimalizátor dotazů předvádí. Vše si ukážeme na následujících příkladech:

Nejprve si vytvoříme tabulku #TestData a naplníme ji testovacími daty:

CREATE TABLE #TestTable (ID INT NOT NULL,
			 VALUE NVARCHAR(128))

INSERT INTO #TestTable (ID, VALUE)
	SELECT TOP (10000) ROW_NUMBER() OVER(ORDER BY (SELECT NULL)), v1.name
	FROM spt_values v1
		CROSS JOIN spt_values v2
	WHERE v1.name like '%PROCEDURE%'
	ORDER BY NEWID()
GO

Nyní budeme zkoušet jednotlivé kombinace CTE a sledovat exekuční plány. Ve všech příkladech přidáváme nakonec query hint MAXDOP(1), abychom se pro zjednodušení vyhnuli paralelnímu exekučním plánu.

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT * FROM CTE1
),
CTE3 AS
(
	SELECT * FROM CTE2
)
SELECT * FROM CTE1
UNION ALL
SELECT * FROM CTE2 
UNION ALL
SELECT * FROM CTE3
OPTION(MAXDOP 1)
GO

V tomto dotazu nejprve v CTE1 filtrujeme data z #TestTable a dále tento výsledek referencujeme v CTE2 a CTE2 opět v CTE3. Očekávali bychom, že SQL Server vykoná jedno čtení z tabulky #TestData v rámci CTE1, a že CTE2 a CTE3 budou pouze syntaktickým odpadem. Exekuční plán však vypadá takto:

SQL Server ve skutečnosti četl zdrojovou tabulku třikrát, a pokud se podíváme na detail jednotlivých Table Scan operátorů, vidíme, že jsou identické a všechny obsahují podmínku WHERE:

Nyní změníme náš příklad a budeme se dotazovat pouze na data z CTE3:

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT * FROM CTE1
),
CTE3 AS
(
	SELECT * FROM CTE2
)
SELECT * FROM CTE3
OPTION(MAXDOP 1)
GO

Nyní nás již optimalizátor nezklamal a vidíme, že scanoval #TestTable pouze jednou. Správně dovodil, že CTE2 a CTE3 na samotném výsledku nic nemění. Stejně chytře se optimalizátor vypořádá i s případným dalším filtrování CTE1 v CTE2 a CTE3.

Pokud ovšem například v CTE3 sáhneme po komplexnější operaci, může nás optimalizátor opět poněkud překvapit:

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT * FROM CTE1
),
CTE3 AS
(
	SELECT CTE1.ID, CTE2.VALUE FROM CTE2 INNER JOIN CTE1 ON CTE1.ID = CTE2.ID
)
SELECT * FROM CTE3
OPTION(MAXDOP 1)
GO

Z exekučního plánu vidíme, že sice došlo k eliminaci CTE2, ale pro provedení joinu SQL Server musel provést opravdu dva scany stejné tabulky, aby byl schopen vytvořit výslednou sadu řádků.

Následující dva příklady nám ukážou, že někdy je optimalizátor neobyčejně chytrý:

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT COUNT(*) Cnt FROM CTE1
)
SELECT * FROM CTE2
OPTION(MAXDOP 1)
GO

Vidíme pouze jeden Table Scan, tedy očekávaný výsledek. Nyní udělejme drobnou úpravu a přidejme CTE3:

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT COUNT(*) Cnt FROM CTE1
),
CTE3 AS
(
	SELECT COUNT(*) Cnt FROM CTE2
)
SELECT * FROM CTE3
OPTION(MAXDOP 1)
GO

Výsledek je opravdu překvapivý: optimalizátor provedl logickou eliminaci, kdy správně určil, že výsledek vždy bude 1, protože CTE3 se dotazuje do CTE2, která vždy vrátí pouze jeden řádek. Není tedy vůbec třeba přistupovat ke zdrojovým datům a výsledek dotazu lze určit pouze jeho logickou analýzou.

Poslední zajímavé chování nám ukazuje následující dotaz:

WITH CTE1 AS
(
	SELECT * FROM #TestTable WHERE VALUE LIKE '%PROCEDURE%'
),
CTE2 AS
(
	SELECT * FROM CTE1 WHERE VALUE LIKE '%filter%'
),
CTE3 AS
(
	SELECT * FROM CTE2
)
SELECT * 
FROM CTE1
	INNER JOIN CTE3 ON CTE3.ID = CTE1.ID
OPTION(MAXDOP 1)
GO

Vidíme opět dva Table Scan operátory, ale u druhého z nich nám predikát ukazuje, že SQL  Server složil obě podmínky do jedné pomocí AND:

Z výše uvedeného je zřejmé, že CTE (mimo její rekurzivní funkce) je pouze syntaktickým konstruktem a při jejím spojování nelze o jednotlivých CTE uvažovat jako o dočasném datovém setu, který SQL Server vytváří někde na pozadí a následně používá pro další zpracování. Ve většině případů můžeme dosáhnout stejného nebo lepší výkonu konvenčním zápisem, např. náš poslední dotaz můžeme zapsat i takto:

SELECT ID, VALUE
FROM #TestTable 
WHERE VALUE LIKE '%PROCEDURE%' AND VALUE LIKE '%filter%'
GO

Odměnou je nám jednoduchý exekuční plán přesně dle očekávání:

COLLATE

Řešení problémů s výběrem správné kolace je jednoduché: stačí využít COLLATE direktivu stejně jako v jakýchkoliv jiných případech, např. když  joinujeme sloupce napříč databázemi s rozdílnou kolací:

SELECT * 
FROM dbo.SampleTable 
WHERE Col1 LIKE '[a-d]%' COLLATE Latin1_General_BIN

Takto jednoduše můžeme u LIKE zařídit třeba hledání všech řetězců, které začínají na písmena a až d, což pro anglickou kolaci znamená písmena a,b,c,d, kdežto pro českou a,b,c,č,d.

ESCAPE

ESCAPE direktivu budeme potřebovat vždy, když chceme hledat řetězce, které obsahují některé speciální znaky, které běžně využíváme v podmínce LIKE pro nastavení jejího chování, např. %, _ , [ atd.

ESCAPE funguje tak, že pomocí něho můžeme určit, že námi zvolený znak bude využíván jako značka, kterou umístíme před speciální znaky a tím je označíme tak, že již nebudou plnit svoji speciální funkci, ale budou považovány za běžný řetězec.
V příkladu níže vidíme, že jsme zvolili zpětné lomítko ‘/’ jako separátor speciálních znaků.
Nebudeme tedy hledat všechny řetězce začínající na ‘Novak’, tedy např. Nováková, ale místo toho hledáme všechny výskyty řetězce ‘Novak%’.

SELECT * FROM dbo.Person WHERE Surname LIKE 'Novák/%' ESCAPE '/'

Vytvoříme si testovací tabulku s jedním sloupcem ID, do kterého vyplníme pět hodnot, z nichž jedna je NULL:

CREATE TABLE [dbo].[SampleTable](
 [ID] [int] NULL
) ON [PRIMARY]
GO

INSERT INTO [dbo].[SampleTable] 
 ([ID])
 SELECT 1 UNION ALL
 SELECT 2 UNION ALL
 SELECT 3 UNION ALL
 SELECT NULL UNION ALL
 SELECT 5
GO

Nyní spustíme tyto dva dotazy a porovnáme jejich výstup:

SELECT COUNT(*) FROM dbo.SampleTable

SELECT COUNT(ID) FROM dbo.SampleTable
GO

První dotaz s COUNT(*) nám vrátil pět řádků, protože COUNT() s aterixem (*) nám vrací počet řádků přes všechny sloupce = celou tabulku. COUNT(ID) provádí agregaci nad konkrétním sloupcem a zde se chová jako jiné agregační funkce a hodnoty NULL ignoruje. Proto je v prvím případě výsledek 5 (celkový počet řádků v tabulce) a ve druhém 4 (počet NOT NULL hodnot ve sloupci ID).

Že se nejedná o příliš intuitivní chování, ale hlavně se nejedná o přesnou implementaci ANSI standardu SQL, nás SQL Server upozorní v okně zpráv, kde se po vykonání druhého dotazu zobrazí následující varování:

Varování můžeme potlačit nastavením SET ANSI_WARNINGS { ON | OFF }, které je ve výchozím nastavením ON, případně lze varování potlačit pro celý server a všechna připojení pomocí sp_configure. Změnu tohoto nastavení však nezle doporučit a pro řadu operací je vyžadováno nastavení SET_ANSI_WARNINGS na výchozí hodnotu ON.

How that works is presented in this simple example:

;WITH cte(Value)
AS
(
    SELECT CONVERT(VARCHAR(1000),'Anchor1_') 
    UNION ALL
    SELECT CONVERT(VARCHAR(1000),'Anchor2_') 
    UNION ALL
    SELECT CONVERT(VARCHAR(1000), Value + 'x') 
    FROM cte
    WHERE LEN(Value) < 15    
)
SELECT *
FROM cte
ORDER BY LEN(Value)

We have created two anchor rows: Anchor1_ and Anchor2_. Then we are running recursive iteration over it adding an ‘x’ in every step until the total length of the string is 15. Instead of UNION ALL we can use any kind of option on how to create a multirow anchor dataset like VALUES() or standard SELECT statement.

-- Using constant value
SELECT TOP 10 * -- (10)
FROM sys.messages
GO

-- Using percents
SELECT TOP 10 PERCENT * -- (10) PERCENT
FROM sys.messages
GO

-- Using variable
DECLARE @Cnt INT
SET @Cnt = 10

SELECT TOP (@Cnt) * FROM sys.messages
SELECT TOP (@Cnt) PERCENT * FROM sys.messages
GO

-- Using subquery
SELECT TOP (SELECT COUNT(*)/10 FROM sys.messages) *
FROM sys.messages