Poisé… alguns dos meus posts anteriores trataram de Common Table Expressions e eu não mencionei outra característica muito interessante.

Lembram que o result set da CTE só existe no escopo da query seguinte? Mas será que não é possivél eu ir juntando várias CTE’s e no final fazer uma query que manipule o conjunto de todas?

É sim! Vejam o seguinte exemplo:

;WITH cteA(a)
AS
(
    SELECT 1
    UNION ALL
    SELECT a + 1 FROM cteA WHERE a < 10
), cteB(b)
AS
(
    SELECT 1
    UNION ALL
    SELECT b + 1 FROM cteB WHERE b < 10
), cteC(c)
AS
(
    SELECT 5
)
SELECT ((SELECT SUM(b) from cteB) + (SELECT SUM(a) from cteA)) /
((SELECT COUNT(b) from cteB) + (SELECT COUNT(a) from cteA)) *
(SELECT c FROM cteC)

São 3 CTEs sendo executadas. O retorno das duas primeiras já nos é conhecido: é a contagem de 1 a 10 (visto no post anterior), e o retorno da última é 5, bastante trivial.

Esse post não serve apenas para demonstrar essa capacidade, mas também para alertar para os perigos que podem vir atrelados.

E o meu recado é: CUIDADO com a comodidade! Senão a legibilidade ganha com as CTEs de nada servirá. A explicação é facilmente observada através do plano de execução da query acima.

StmtText
----------------------------------------------------------------------------------------------------------------------
  |--Compute Scalar(DEFINE:([Expr1026]=(([Expr1004]+[Expr1010])/([Expr1016]+[Expr1022]))*(5)))
       |--Nested Loops(Inner Join)
            |--Nested Loops(Inner Join)
            |    |--Nested Loops(Inner Join)
            |    |    |--Compute Scalar(DEFINE:([Expr1004]=CASE WHEN [Expr1045]=(0) THEN NULL ELSE [Expr1046] END))
            |    |    |    |--Stream Aggregate(DEFINE:([Expr1045]=COUNT_BIG([Recr1003]), [Expr1046]=SUM([Recr1003])))
            |    |    |         |--Index Spool(WITH STACK)
            |    |    |              |--Concatenation
            |    |    |                   |--Compute Scalar(DEFINE:([Expr1041]=(0)))
            |    |    |                   |    |--Constant Scan(VALUES:(((1))))
            |    |    |                   |--Assert(WHERE:(CASE WHEN [Expr1043]>(100) THEN (0) ELSE NULL END))
            |    |    |                        |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1043], [Recr1001]))
            |    |    |                             |--Compute Scalar(DEFINE:([Expr1043]=[Expr1042]+(1)))
            |    |    |                             |    |--Table Spool(WITH STACK)
            |    |    |                             |--Compute Scalar(DEFINE:([Expr1002]=[Recr1001]+(1)))
            |    |    |                                  |--Filter(WHERE:(STARTUP EXPR([Recr1001]<(10))))
            |    |    |                                       |--Constant Scan
            |    |    |--Compute Scalar(DEFINE:([Expr1022]=CONVERT_IMPLICIT(int,[Expr1051],0)))
            |    |         |--Stream Aggregate(DEFINE:([Expr1051]=COUNT([Recr1021])))
            |    |              |--Index Spool(WITH STACK)
            |    |                   |--Concatenation
            |    |                        |--Compute Scalar(DEFINE:([Expr1047]=(0)))
            |    |                        |    |--Constant Scan(VALUES:(((1))))
            |    |                        |--Assert(WHERE:(CASE WHEN [Expr1049]>(100) THEN (0) ELSE NULL END))
            |    |                             |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1049], [Recr1019]))
            |    |                                  |--Compute Scalar(DEFINE:([Expr1049]=[Expr1048]+(1)))
            |    |                                  |    |--Table Spool(WITH STACK)
            |    |                                  |--Compute Scalar(DEFINE:([Expr1020]=[Recr1019]+(1)))
            |    |                                       |--Filter(WHERE:(STARTUP EXPR([Recr1019]<(10))))
            |    |                                            |--Constant Scan
            |    |--Compute Scalar(DEFINE:([Expr1016]=CONVERT_IMPLICIT(int,[Expr1056],0)))
            |         |--Stream Aggregate(DEFINE:([Expr1056]=COUNT([Recr1015])))
            |              |--Index Spool(WITH STACK)
            |                   |--Concatenation
            |                        |--Compute Scalar(DEFINE:([Expr1052]=(0)))
            |                        |    |--Constant Scan(VALUES:(((1))))
            |                        |--Assert(WHERE:(CASE WHEN [Expr1054]>(100) THEN (0) ELSE NULL END))
            |                             |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1054], [Recr1013]))
            |                                  |--Compute Scalar(DEFINE:([Expr1054]=[Expr1053]+(1)))
            |                                  |    |--Table Spool(WITH STACK)
            |                                  |--Compute Scalar(DEFINE:([Expr1014]=[Recr1013]+(1)))
            |                                       |--Filter(WHERE:(STARTUP EXPR([Recr1013]<(10))))
            |                                            |--Constant Scan
            |--Compute Scalar(DEFINE:([Expr1010]=CASE WHEN [Expr1061]=(0) THEN NULL ELSE [Expr1062] END))
                 |--Stream Aggregate(DEFINE:([Expr1061]=COUNT_BIG([Recr1009]), [Expr1062]=SUM([Recr1009])))
                      |--Index Spool(WITH STACK)
                           |--Concatenation
                                |--Compute Scalar(DEFINE:([Expr1057]=(0)))
                                |    |--Constant Scan(VALUES:(((1))))
                                |--Assert(WHERE:(CASE WHEN [Expr1059]>(100) THEN (0) ELSE NULL END))
                                     |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1059], [Recr1007]))
                                          |--Compute Scalar(DEFINE:([Expr1059]=[Expr1058]+(1)))
                                          |    |--Table Spool(WITH STACK)
                                          |--Compute Scalar(DEFINE:([Expr1008]=[Recr1007]+(1)))
                                               |--Filter(WHERE:(STARTUP EXPR([Recr1007]<(10))))
                                                    |--Constant Scan

Poisé, é executado tudo separado. Se houverem processamento desnecessários nas CTEs, poderemos encontrar sérios gargalos nestas querys!

Então pessoal, era mais isso que eu queria mostrar deste fantástico recurso! Usem CTE’s, e para os que usarem, usem sabendo como funcionam! :)

E para quem não acompanhou, segue os links dos posts anteriores:

Entendendo as Common Table Expressions – CTE – Parte 1

http://thiagozavaschi.spaces.live.com/blog/cns!8DE5A8EFC1819ECA!390.entry

Entendendo as Common Table Expressions – CTE – Parte 2 (Final)

http://thiagozavaschi.spaces.live.com/blog/cns!8DE5A8EFC1819ECA!391.entry

Abraços,
Thiago Zavaschi

Bom, mostrei um pouco de teoria, mostrei alguns exemplos didáticos (o de números é bastante utilizado na prática), mas vamos ver mais alguns exemplos:

Vou começar com um exemplo já mostrado aqui no blog (sim, finalmente este é o post sobre o qual falei no referido post :) ).

Este é o método baseado em CTE para realizar Split no SQL Server (atentar para o limite da recursividade, se necessário usar o maxrecursion).

DECLARE @s VARCHAR(8000), @d VARCHAR(10)
SET @s = 'separar por espaço em branco'
SET @d = ' ' 

;WITH split(i,j) AS
(
SELECT i = 1, j = CHARINDEX(@d, @s + @d)
UNION ALL
SELECT i = j + 1, j = CHARINDEX(@d, @s + @d, j + 1) FROM split
   WHERE CHARINDEX(@d, @s + @d, j + 1) <> 0
)
SELECT SUBSTRING(@s,i,j-i)
FROM split

O método é facilmente adaptável para o seu outro grande uso: parser de textos CSV. Basta apenas trocar o delimitador. Simples não?

DECLARE @s VARCHAR(8000), @d VARCHAR(10)
SET @s = '123;4;thiago@zavaschi.com;2232323'
SET @d = ';' 

-- Continuação mostrada anteriormente.

Um exemplo interessante que sempre cobro em aula (acho que vou ter que parar de cobrar :P) é para realizar o exemplo clássico do fatorial. O resultado final eu diria ser muito elegante.

WITH fat(f, n) AS
(
    SELECT CAST (1 as bigint) as f, 0  as n -- fat de 0 é 1
    UNION ALL
    SELECT CAST (1 as bigint) as f, 1 as n -- fat de 1 é 1
    UNION ALL
    SELECT f * (n + 1), n +1
    FROM fat
    WHERE n < 20 AND n <> 0
    -- 20 é o limite neste caso, pois o fatorial de 21 
    -- não cabe em um tipo bigint. O <> 0 é para cortar a recursão
    -- do primeiro âncora, senão repetiria tudo, faça o teste. 
)
SELECT f
FROM fat
WHERE n = 6 -- troque n pelo fatorial que quer calcular

Para melhorar a legibilidade das queries. podemos encapsular isso em uma função:

CREATE FUNCTION fatorial
(
    @n INT
)
RETURNS INT
AS
BEGIN
    DECLARE @val INT;
    WITH fat(f, n) AS
    (
        SELECT CAST (1 as bigint) as f, 0  as n
        UNION ALL
        SELECT CAST (1 as bigint) as f, 1 as n
        UNION ALL
        SELECT f * (n + 1), n +1
        FROM fat
        WHERE n < 20 AND n <> 0
    )
    SELECT @val = f
    FROM fat
    WHERE n = @n
    RETURN @val
END
GO

-- Testando a função
SELECT dbo.fatorial(3);
SELECT dbo.fatorial(4);
SELECT dbo.fatorial(7);

(Abrindo um parênteses importante:

A única resalva que faço é quanto a estes calculos matemáticos intensos em queries. O SQL Server trabalha muito bem com as ditas set based operations. ou seja, operações baseadas em conjuntos. Operações envolvendo manipulação de strings e cálculos matemáticos complexos não são o forte do SQL Server. Como resolver então, de outra maneira?

Desde o SQL Server 2005 (apareceu junto com as CTEs) o SQL Server tem a CLR integrada ao seu core. Isso quer dizer que é possível criar objetos para o SQL Server (User Defined Types – UDT, Stored Procedures, Functions, etc) programando em uma linguagem compatível com a Common Language Runtime e adicionar o assembly gerado ao seu banco SQL Server. Não fiz testes para esse exemplo do fatorial (farei em um futuro breve), mas é provável que o tempo de execução seja menor se o mesmo estivesse sendo executado pela CLR.

Farei um post detalhando melhor e também na Mundo.NET da edição de Dezembro/2009 sairá um artigo meu sobre como programar com SQLCLR usando C#!

Fechando o parênteses muito importante)

Para o próximo exemplo eu preciso fazer algumas considerações.

Com o SQL Server 2008 surgiu o tipo de dados HIERACHYID e que é, na minha visão, o melhor método de se trabalhar com registros que possuem comportamento hierárquico. Por uma série de motivos: o banco é SQL Server 2005 (ou esta com Compability Level 90), ou é uma estrutura legada, e se você deseja tratar hierarquias?

Commom Table Expressions podem fazer, e fazem, esse papel muito bem. Digamos que temos uma estrutura hirárquica de empregados e cada registro faz uma referência a outro registro que seria o seu supervisor dentro de uma empresa. O diretor da empresa não possui ligação com ninguém, uma vez que ele não teria um supervisor.

Para esse exemplo poderia usar a tabela de empregados do AdventureWorks, mas como nem sempre todos a possuem instalada (deveriam, pois há centenas de exemplos que a utilizam), eu mesmo montarei uma pequena “base”.

Segue o modelo de dados e script para criação da estrutura.

-- Cria tabela base
CREATE TABLE Empregado
(
    id INT PRIMARY KEY,
    nome VARCHAR(50) NOT NULL,
    cargo VARCHAR(50) NOT NULL,
    id_supervisor INT NULL
        CONSTRAINT fk_productSales_pid
        FOREIGN KEY REFERENCES Empregado(id)
);

-- Popula a tabela (reparem na sintaxe do insert, 
-- só é permitida no SQL Server 2008 ou superior).
INSERT INTO Empregado VALUES
(1, 'Thiago Zavaschi', 'Diretor', null),
(2, 'Angelina Jolie', 'Gerente de Vendas', 1),
(3, 'Megan Fox', 'Gerente de Marketing', 1),
(4, 'Uma Thurman', 'Vendedor', 2),
(5, 'Jessica Alba', 'Vendedor', 2),
(6, 'Julia Roberts', 'Estagiário', 3);

Ao executar um simples select nesta tabela temos:

id       nome                       cargo                            id_supervisor
-------- -------------------------- -------------------------------- -------------
1        Thiago Zavaschi            Diretor                          NULL
2        Angelina Jolie             Gerente de Vendas                1
3        Megan Fox                  Gerente de Marketing             1
4        Uma Thurman                Vendedor                         2
5        Jessica Alba               Vendedor                         2
6        Julia Roberts              Estagiário                       3

Creio que todos deverão concordar comigo que esta visulização torna praticamente impossível a noção de hierarquia (e olhe que temos poucos registros, imagine termos centenas dos mesmos.

É fácil retornar qual é o nome do supervisor, mas isso de maneira recursiva não seria nada tranquilo. Vou montar uma query que me retorne o nível da pessoa na hierarquia. Ou seja, para o Diretor o valor será 1, para os gerentes será 2, e para o restante será 3. Com a minah CTE retornando isso, a query subsequente, que consome a CTE podera formatar os resultados, filtrar, enfim, tudo baseado no resultado da consulta recursiva já processada, bacana né? Vamos lá!

;WITH hierarquia(id, nome, cargo, id_supervisor, nivel_hierarquia)
AS
(
    SELECT  id, nome, cargo, id_supervisor, 1 as nivel_hierarquia
    FROM Empregado
    WHERE id_supervisor IS NULL
    -- Perceba que aqui no âncora temos como retorno somente o diretor.
    UNION ALL -- Ligação para a recursão
    SELECT e.id, e.nome, e.cargo, e.id_supervisor, nivel_hierarquia + 1
    FROM Empregado e
    INNER JOIN hierarquia h ON h.id= e.id_supervisor
)
SELECT * FROM hierarquia

A saída deste script é (reparem na coluna nivel_herarquia):

id       nome                 cargo                       id_supervisor nivel_hierarquia
-------- -------------------- --------------------------- ------------- ----------------
1        Thiago Zavaschi      Diretor                     NULL          1
2        Angelina Jolie       Gerente de Vendas           1             2
3        Megan Fox            Gerente de Marketing        1             2
6        Julia Roberts        Estagiário                  3             3
4        Uma Thurman          Vendedor                    2             3
5        Jessica Alba         Vendedor                    2             3

“Ok thiago, mas ainda assim não estou conseguindo visualizar, por exemplo, quem é o supervisor, tem como melhorar?”

Tem sim. uma das utilidades das CTEs é: a mesma retornar um result set “complexo de ser calculado” (como o caso da hierarquia) e deixar para o select mais abaixo fazer a formatação/filtragem/ordenação. Isso eixar a estrutura da sua CTE mais genérica e menos “engessada”, fazendo até mesmo com que você possa reaproveitar esse código em outro lugar.

Por exemplo: quero uma listagem com todo o time operacional (maior valor em nivel_hierarquia) da empresa, com seus respectivos supervisores. A query poderia ficar assim:

;WITH hierarquia(id, nome, cargo, id_supervisor, nivel_hierarquia)
AS
(
    SELECT  id, nome, cargo, id_supervisor, 1 as nivel_hierarquia
    FROM Empregado
    WHERE id_supervisor IS NULL
    -- Perceba que aqui no âncora temos como retorno somente o diretor.
    UNION ALL -- Ligação para a recursão
    SELECT e.id, e.nome, e.cargo, e.id_supervisor, nivel_hierarquia + 1
    FROM Empregado e
    INNER JOIN hierarquia h ON h.id= e.id_supervisor
)
SELECT
h.nome + '/' + h.cargo as [Operacional], -- perceba a formatação ocorrendo aqui
s.nome + '/' + s.cargo as [Tático]
FROM hierarquia h JOIN Empregado s ON h.id_supervisor = s.id
WHERE h.nivel_hierarquia =
(SELECT MAX(nivel_hierarquia) FROM hierarquia) -- perceba que o filtro ocorreu aqui

Com o seguinte output:

Operacional                     Tático
------------------------------- ------------------------------------
Julia Roberts/Estagiário        Megan Fox/Gerente de Marketing
Uma Thurman/Vendedor            Angelina Jolie/Gerente de Vendas
Jessica Alba/Vendedor           Angelina Jolie/Gerente de Vendas

Tranquilo né? E assim poderíamos evoluir de “N” formas, cada uma atendendo a uma necessidade específica.

Common table Expressions também podem ser utilizadas de outras formas, para fazer tratamento de datas, carga, e muitas outras funções (ver links no final do post para maiores informações).

O que mais saber sobre Common Table Expressions (CTE) ?

Bom, já vimos bastante coisa sobre o que é uma CTE, como funciona, onde se aplica (com alguns exemplos), mas o que mais devemos saber?

Devemos saber que há restrições sobre oq eu podemos usar ou não em CTEs. Vou listar alguams das que eu considero principais (no Books Online – BOL, há a lista completa, ver link ao final do post).

Bom acredito que a primeira coisa que é importante saber é que NÃO é permitido fazer uma referência recursiva dentro de uma subquery. Vou usar o exemplo anterior para demonstrar:

...
UNION ALL
    SELECT e.id, e.nome, e.cargo, e.id_supervisor,
    (SELECT h.nivel_hierarquia_2 FROM hierarquia) -- ISSO NÃO É PERMITIDO.
    FROM Empregado e
    ...
)
...

O que nos gera um erro similar a:

Msg 465, Level 16, State 1, Line 32
Recursive references are not allowed in subqueries.

O que mais não é permitido na definição do membro recursivo? Segue a lista:

• SELECT DISTINCT
• GROUP BY
• HAVING
• Scalar aggregation
• TOP
• LEFT, RIGHT, OUTER JOIN (obs: o INNER JOIN é permitido)
• A hint applied to a recursive reference to a CTE inside a CTE_query_definition.

Você, leitor, deve ter percebido que eu normalmente iniciei minhas CTE’s com um ponto e vírgula (‘;’), não, não fiquei maluco e nem coloquei por engano.
A questão é que a sintaxe para execução da CTE obriga que o statement anterior termine com ponto e vírgula, então acabo sempre colocando, já que o statement anterior normalmente não possui “;” ao seu término!

Há algumas guidelines no books online e vou apenas trancrever aqui, em inglês mesmo (consultar o link no final para o texto completo – em inglês), omiti sobre o maxrecursion que eu já comentei.

Using CLR Integration in SQL Server 2005 (Se alguém quiser ir se adiantando um pouco no assunto!)
http://msdn.microsoft.com/en-us/library/ms345136%28SQL.90%29.aspx

Finalizando

UFA! Bom pessoal, espero que todos tenham chegado até aqui, e espero também que gostem tanto do artigo quanto eu gostei de fazê-lo!

Utilizem como referência para consultas futuras e qualquer sugestão estou aberto para ouvir!

Comentei que há o tipo de dados HIERARCHYID, presente no SQL Server 2008 e superirores) para manipular registros essencialmente hierárquicos, mas acho que isso não compete a este post, abordo isso mais profundamente numa próxima oportunidade!

Grande abraço!
Thiago Zavaschi

PS: Tive que dividir o artigo em duas partes, pois o Spaces não deixa publicar posts grandes (para a primeira parte veja o post anterior).

A uma primeira vista parece que as coisas “complicaram”, mas depois de escrever uma ou duas CTE’s é facilmente perceptível o quão fácil (e vantajoso) é trabalhar com as mesmas.

Antes de dar uma descrição formal de uma CTE, vou executar um dos exemplos mais simples que pode ser feito.

;WITH Simples(valor, nome)
AS
(
    SELECT 1, 'thiago'
)
SELECT * FROM Simples

E o resultado é:

valor       nome
----------- ------
1           thiago

(1 row(s) affected)

Ahmm, ok, eu poderia ter feito o mesmo usando simplesmente algo como:

SELECT 1, 'thiago' 

Mas a vantagem (a primeira das muitas) é que você pode referenciar várias vezes a cte em sua query. Mas antes de demonstrar isso, creioq eu cabe a necessidade de uma definição formal do que seja uma Common Table Expression. Definição segundo o Books Online do SQL Server 2008:

Uma CTE (Common Table Expression) pode ser encarada como um result set que tem seu escopo definido pela execução de um única cláusula SELECT, INSERT, UPDATE, DELETE ou CREATE VIEW. O result set da CTE existe apenas durante a execução da query.
Uma CTE tem duas grandes capacidades: pode se auto referenciar (CTE recursiva) e pode ser referenciada várias vezes na mesma query.

A sintaxe de uma CTE é demonstrada a seguir:

WITH expression_name [ ( column_name [,...n] ) ]
AS
( CTE_query_definition )

A lista de nomes de colunas é opcional somente se a query da CTE retornar colunas com nomes únicos. Contudo, é uma boa prática definir os nomes.

O comando para rodar a CTE seria:

SELECT <column_list>
FROM expression_name;

Um exemplo de uma CTE sendo referenciada várias vezes na mesma query:

;WITH VariasVezes(valor)
AS
(
    SELECT 1
    UNION
    SELECT 33
    UNION
    SELECT 8
)
SELECT
(SELECT MAX(valor) FROM VariasVezes) +
(SELECT SUM(valor) FROM VariasVezes) AS val

Perceba que no select que consome a CTE eu a referenciei (“VariasVezes”) duas vezes. Cuidado que nas funções agregadas o conteúdo da CTE sofre scan para cada função agregada, e, dependendo, uma abordagem diferente pode ser mais performática, mas ganha-se muito com a legibilidade da query. Observe os scans no plano de execução da CTE VariasVezes.

Para facilitar a análise, segue o plano de execução em modo texto (instrução SET SHOWPLAN_TEXT).

StmtText
----------------------------------------------------------------------------------------------------------
  |--Compute Scalar(DEFINE:([Expr1012]=[Expr1004]+[Expr1010]))
       |--Nested Loops(Inner Join)
            |--Stream Aggregate(DEFINE:([Expr1004]=MAX([Union1003])))
            |    |--Concatenation
            |        |--Constant Scan(VALUES:(((1))))
            |         |--Constant Scan(VALUES:(((33))))
            |         |--Constant Scan(VALUES:(((8))))
            |--Compute Scalar(DEFINE:([Expr1010]=CASE WHEN [Expr1019]=(0) THEN NULL ELSE [Expr1020] END))
                 |--Stream Aggregate(DEFINE:([Expr1019]=Count(*), [Expr1020]=SUM([Union1009])))
                      |--Concatenation
                          |--Constant Scan(VALUES:(((1))))
                           |--Constant Scan(VALUES:(((33))))
                           |--Constant Scan(VALUES:(((8))))

Essa característica já seria o suficiente para tornar o uso de CTEs muito interessante, mas na minha opinião a capacidade de auto-referenciar (queries recursivas) é que torna CTE um recurso tão poderoso.

Queries Recursivas com Common Table Expressions

Como já mencionei as CTEs podem se auto referenciar, isto é, dentro da própria definição da CTE.
Já ministrei diversos treinamentos em que CTE era um dos itens da ementa, e percebi que o melhor jeito de entender o funcionamento das mesmas é através de exemplos. Começarei com alguns simples e vou até alguns mais elaborados, com o passo a passo de cada execução para facilitar. :)

Vamos pensar um pouco, em que seria interessante a utilização de uma query recursiva? O exemplo clássico seria o cálculo de fatorial (faremos mais adiante), geração de números sequênciais, etc, etc.

Mas para usar uma CTE recursiva basta apenas referenciar ela mesma? Sim e não, na verdade não. É necessário a utilização do operador UNION ALL além da introdução de dois novos termos/conceitos: Membro Âncora e o Membro Recursivo. Segue a estruturação na forma de um exemplo que gera números sequênciais de 1 até 10:

;WITH NumerosSequenciais(num)
AS
(
     SELECT 1 AS num -- Este é o membro âncora, será o primeiro a ser executado. 
     UNION ALL -- Fará a ligação do membro âncora com o membro recursivo.
     SELECT num + 1 AS num FROM NumerosSequenciais
     WHERE num < 10 -- perceba que o WHERE é bastante importante para delimitar a parada da recursão.
)
SELECT * FROM NumerosSequenciais

Uma coisa comum, que vejo muitos se confundirem (o que é razoavél, uma vez que essa recursão é um pouco diferente das demais), é achar que o membro âncora será o critério de parada, e isso NÃO é verdade. Na realidade, ele é o primeiro a ser executado. O critério de parada é o membro recursivo parar de fornecer novas linhas de retorno para serem “processadas”. Veja a execução do passo a passo mais adiante.

Segue mais um exemplo, mas agora manipulando um elemento do tipo VARCHAR. Um ponto importante a se observar é que não funcionará sem a utilização da função CONVERT, e se deve ao fato de que os (os? veja adiante) membros âncoras e recursicos (plural novamente? veja adiante)  devem retornar o mesmo tipo de dado em cada coluna (no caso, VARCHAR(4000)).

;WITH Nome(nome)
AS
(
    SELECT nome = CONVERT(VARCHAR(4000),'Thiago')
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Zavaschi') FROM Nome
    WHERE LEN(nome) < 30
)
SELECT nome FROM Nome

O resultado da query recursiva acima é:

Thiago
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

Queries recursivas com mais de um membro âncora/recursivo

Aqui é que as coisas podem parecer confusas (e até são de certo modo), tenho que confessar que nunca (que eu me lembre) precisei usar mais de um membro recursivo na mesma CTE, mas devemos conhecer todas as possibilidades!

Vamos voltar a query anterior que concatenava ‘Zavaschi’ ao nome ‘Thiago’ e adicionarei um novo âncora.

Mas e como fazer isso? Basta adicionar mais um SELECT que não faça referência à propria CTE (senão seria um membro recursivo, hehe). o resultado fica algo parecido com:

;WITH Nome(nome)
AS
(
    SELECT nome = CONVERT(VARCHAR(4000),'Thiago')
    UNION ALL
    SELECT nome = CONVERT(VARCHAR(4000),'José')
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Zavaschi') FROM Nome
    WHERE LEN(nome) < 30
)
SELECT nome FROM Nome

Conseguem imaginar o que irá acontecer? Na verdade o que eu acho que um desenvolvedor tem que se preocupar é a ORDEM com que será retornado os registros (supondo que já haja um entendimento sobre CTEs).

O resultado desta query é:

nome
-------------------------------------
Thiago
José
JoséZavaschi
JoséZavaschiZavaschi
JoséZavaschiZavaschiZavaschi
JoséZavaschiZavaschiZavaschiZavaschi
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

(9 row(s) affected)

Por que isso ocorre? Ou melhor, “me explica o que ocorreu”. Vamos lá! Obs: vou ir negritando os registros e colocando a query que foi “executada” para facilitar no entendimento do output encontrado.

1) Como a “parte” que é executada primeiro é a da âncora, ou das âncoras, e por ordem no UNIOL ALL, temos o ‘Thiago’ e depois o ‘José’.

SELECT nome = CONVERT(VARCHAR(4000),'Thiago')
UNION ALL
SELECT nome = CONVERT(VARCHAR(4000),'José')

Thiago
José
JoséZavaschi
JoséZavaschiZavaschi
JoséZavaschiZavaschiZavaschi
JoséZavaschiZavaschiZavaschiZavaschi
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

2) Foram executados os âncoras agora é a vez da execução do membro recursivo.

SELECT CONVERT(VARCHAR(4000),nome + 'Zavaschi') FROM Nome
    WHERE LEN(nome) < 30

O conteúdo do “nome” atual é “José” (última âncora selecionada), perceba que no FROM temos referenciada a própria CTE!

A execução da query seria algo como (de maneira BEM simplificada):

SELECT ‘José’ + 'Zavaschi' WHERE LEN(‘José’ + 'Zavaschi') < 30

Esse registro retornou alguma linha? Sim. então continua processando esta query recursiva.

Thiago
José
JoséZavaschi
JoséZavaschiZavaschi
JoséZavaschiZavaschiZavaschi
JoséZavaschiZavaschiZavaschiZavaschi
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

3) Mas qual é o conteúdo do “nome” neste momento? “JoséZavaschi”.

A query recursiva retorna mais alguma linha (atentar para o WHERE)? Sim. entao retorna o valor presente em “nome” e continua.
O processo se mantém enquanto o conteúdo de “nome” atender à nossa restrição no WHERE (o WHERE é feito com o conteúdo de nome da iteracao anterior, ANTES, da concatenação).

Thiago
José
JoséZavaschi
JoséZavaschiZavaschi
JoséZavaschiZavaschiZavaschi
JoséZavaschiZavaschiZavaschiZavaschi
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

4) o Conteúdo de “nome” agora é:  JoséZavaschiZavaschiZavaschiZavaschi que possui mais de 30 caracteres, então a query recursiva não retorna mais registros e se encerra…ria, caso só tivéssemos uma única âncora. Mas o processo continua para a âncora anterior e assim por diante. E é por isto que temos a saída do Thiago, ThiagoZavaschi, e assim por diante.

Thiago
José
JoséZavaschi
JoséZavaschiZavaschi
JoséZavaschiZavaschiZavaschi
JoséZavaschiZavaschiZavaschiZavaschi
ThiagoZavaschi
ThiagoZavaschiZavaschi
ThiagoZavaschiZavaschiZavaschi

5) Quando a query recursiva não retornar mais nada, a CTE verifica se há alguma outra âncora “esperando”, se não há então já temos o result set que servirá de base para o SELECT, INSERT, DELETE, etc., que estiver após a CTE. Caso tenha uma outra âncora, esta será processada e assim por diante.

---

E para mais de um membro recursivo, como ficaria? Bem não vou fazer execução detalha, pois ficaria muito grande e seria muito repetitivo, mas vejam os seguintes scripts (e os testem).

;WITH Nome(nome)
AS
(
    SELECT nome = CONVERT(VARCHAR(4000),'Thiago')
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Zavaschi') FROM Nome
    WHERE LEN(nome) < 30
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Silva') FROM Nome
    WHERE LEN(nome) < 30
)
SELECT nome FROM Nome

Para esse teremos (omitindo o output):
(39 row(s) affected)

E se colocarmos mais uma âncora? Vai dobrar o número de resultados, certo? Errado. Esqueceu do WHERE LEN(nome) < 30?

;WITH Nome(nome)
AS
(
    SELECT nome = CONVERT(VARCHAR(4000),'Thiago')
    UNION ALL
    SELECT nome = CONVERT(VARCHAR(4000),'José')
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Zavaschi') FROM Nome
    WHERE LEN(nome) < 30
    UNION ALL
    SELECT CONVERT(VARCHAR(4000),nome + 'Silva') FROM Nome
    WHERE LEN(nome) < 30
)
SELECT nome FROM Nome

Se utilizarmos os mesmos valores para âncoras e nas partes recursivas aí sim a adição de um âncora dobraria o total atual de registros retornados.

--

Limite de Recursividade

Para este caso utilizarei um dos exemplos já mostrados:

;WITH NumerosSequenciais(num)
AS
(
     SELECT 1 AS num -- Este é o membro âncora, será o primeiro a ser executado. 
     UNION ALL -- Fará a ligação do membro âncora com o membro recursivo.
     SELECT num + 1 AS num FROM NumerosSequenciais
     WHERE num < 10 -- perceba que o WHERE é bastante importante para delimitar a parada da recursão.
)
SELECT * FROM NumerosSequenciais

É conhecido que o resultado desta CTE será uma sequência de 1 até 10. A query a seguir retornaria o que?.

;WITH NumerosSequenciais(num)
AS
(
     SELECT 1 AS num -- Este é o membro âncora, será o primeiro a ser executado. 
     UNION ALL -- Fará a ligação do membro âncora com o membro recursivo.
     SELECT num + 1 AS num FROM NumerosSequenciais
     WHERE num < 1000 -- perceba que o WHERE é bastante importante para delimitar a parada da recursão.
)
SELECT * FROM NumerosSequenciais

O que mudou foi o nosso “critério de parada” permitindo listar até o número 1000, e é isso que vai acontecer, certo?

Errado. A execução será interrompida em um certo momento e teremos um output semelhante a:

1
2
3
…
98
99
100
101
Msg 530, Level 16, State 1, Line 1
The statement terminated. The maximum recursion 100 has been exhausted before statement completion.

“Ahhhhm, não entendi.”

O SQL Server por padrão tem um mecanismo que serve para evitar que “descuidados” larguem queries recursivas infinitas, o que pode compromoter o desempenho do ambiente. É possível colocar um outro valor até o máximo de 32767. Basta adicionar ao final da query o hint: OPTION (maxrecursion <n>). No nosso exemplo anterior ficaria:

;WITH NumerosSequenciais(num)
AS
(
     SELECT 1 AS num -- Este é o membro âncora, será o primeiro a ser executado. 
     UNION ALL -- Fará a ligação do membro âncora com o membro recursivo.
     SELECT num + 1 AS num FROM NumerosSequenciais
     WHERE num < 1000 -- perceba que o WHERE é bastante importante para delimitar a parada da recursão.
)
SELECT * FROM NumerosSequenciais
OPTION (maxrecursion 3000)

Ainda assim a sua recursividade passa do limite de 32767? Então avalie:

É REALMENTE necessária uma recursão maior que isso?

Não há uma maneira alternativa (e menos custosa) de executar a mesma tarefa? Normalmente há.

Nunca precisei na prática, mas é possível colocar “ilimitadas” recursões: basta colocar o valor do “maxrecursion” para 0.
Mas lembro: eu, Thiago Zavaschi, não vejo isso como uma boa prática.

Continua no próximo post..

Então pessoal, atenção que é uma repostagem! O post sobre Common Table Expressions (CTE) e recursividade já está postado! O de CLR ainda não hehe, mas um dia cumpro todas as promessas!

Função Split no SQL Server

Uma função que sempre senti falta no SQL Server é uma função para split, aonde passaríamos dois parâmetros:

• Frase a ser “splitada”.
• Delimitador.

E teríamos uma lista de palavras originadas da frase passada, separada em cada delimitador.

Já desenvolvi várias versões para fazer split, mas a que considero a melhor (e também bastante popular) é a seguinte:

CREATE FUNCTION dbo.fnSplit(
    @frase VARCHAR(max)
  , @delimitador VARCHAR(max) = ','
) RETURNS @result TABLE (item VARCHAR(8000)) 

BEGIN
DECLARE @parte VARCHAR(8000)
WHILE CHARINDEX(@delimitador,@frase,0) <> 0
BEGIN
SELECT
  @parte=RTRIM(LTRIM(
          SUBSTRING(@frase,1,
        CHARINDEX(@delimitador,@frase,0)-1))),
  @frase=RTRIM(LTRIM(SUBSTRING(@frase,
          CHARINDEX(@delimitador,@frase,0)
        + LEN(@delimitador), LEN(@frase))))
IF LEN(@parte) > 0
  INSERT INTO @result SELECT @parte
END 

IF LEN(@frase) > 0
INSERT INTO @result SELECT @frase
RETURN
END
GO

Para testar é simples:

SELECT * FROM dbo.fnSplit('separar por espaço em branco', ' ')

----

Se desejar, há outra forma, utilizando tabela temporária, sem função:

SET NOCOUNT ON
DECLARE @ARRAY VARCHAR(8000), @DELIMITADOR VARCHAR(100), @S VARCHAR(8000)  

SELECT @ARRAY = 'separar por espaço em branco'
SELECT @DELIMITADOR = ' '  

IF LEN(@ARRAY) > 0 SET @ARRAY = @ARRAY + @DELIMITADOR
CREATE TABLE #ARRAY(ITEM_ARRAY VARCHAR(8000))  

WHILE LEN(@ARRAY) > 0
BEGIN
    SELECT @S = LTRIM(SUBSTRING(@ARRAY, 1,
    CHARINDEX(@DELIMITADOR, @ARRAY) - 1))
    INSERT INTO #ARRAY (ITEM_ARRAY) VALUES (@S)
    SELECT @ARRAY = SUBSTRING(@ARRAY,
    CHARINDEX(@DELIMITADOR, @ARRAY) + 1, LEN(@ARRAY))
END  

-- MOSTRANDO O RESULTADO JÁ POPULADO NA TABELA TEMPORÁRIA  
SELECT * FROM #ARRAY
DROP TABLE #ARRAY
SET NOCOUNT OFF

Simples não?

Estas maneiras mostradas resolvem a necessidade da falta do split? Sim!

Porém, desde o SQL Server 2005 temos o recurso das CTEs (Common Table Expression), que também podem ser utilizadas para split. A seguir mostro o exemplo que considero mais elegante para tal tarefa, utiliza recursividade ao invés do loop:

DECLARE @s VARCHAR(8000), @d VARCHAR(10)
SET @s = 'separar por espaço em branco'
SET @d = ' ' 

;WITH split(i,j) AS
(
SELECT i = 1, j = CHARINDEX(@d, @s + @d)
UNION ALL
SELECT i = j + 1, j = CHARINDEX(@d, @s + @d, j + 1) FROM split
   WHERE CHARINDEX(@d, @s + @d, j + 1) <> 0
)
SELECT SUBSTRING(@s,i,j-i)
FROM split

Observação importante sobre CTEs:

Ao utilizar CTEs recursivas devemos tomar cuidado com o número máximo de recursões permitidas.

Por padrão esse número é igual a 100. Isso na prática significa que eu só poderia ter 100 delimitadores dentro da minha variável @s.

Caso a recursão máxima seja alcançada, termos uma mensagem igual a essa:

“The statement terminated. The maximum recursion 100 has been exhausted before statement completion.”

Para aumentar este valor, podemos acionar um parâmetro extra para a CTE: maxrecursion.

Na prática, para trocar a recursão máxima para 1000, devemos fazer:

DECLARE @s VARCHAR(8000), @d VARCHAR(10)
SET @s = 'separar por espaço em branco'
SET @d = ' ' 

;WITH split(i,j) AS
(
SELECT i = 1, j = CHARINDEX(@d, @s + @d)
UNION ALL
SELECT i = j + 1, j = CHARINDEX(@d, @s + @d, j + 1) FROM split
   WHERE CHARINDEX(@d, @s + @d, j + 1) <> 0
)
SELECT SUBSTRING(@s,i,j-i)
FROM split
OPTION (maxrecursion 1000)

O valor máximo para o parâmetro MAXRECURSION é de 32767, então fiquem atentos. Caso seja necessário uma CTE recursiva com mais de 32767 iterações, então devemos pensar numa estratégia para executar mais de um split (ou mais de uma vez a operação desejada) por iteração. Em casos muito específicos, podemos deixar o máximo de recursão infinito (MAXRECURSION = 0).

Não entendeu muito bem o que é uma CTE? Pode recorrer ao BOL, ou esperar o meu próximo post (há este e o de cursores para postar) que abordarei BEM detalhadamente o que é uma CTE, sintaxe, como funciona, seus usos comuns, e a questão de como funciona a recursividade. Então fiquem atentos! 

---

Depois destas três maneiras mostradas, ainda há uma quarta possibilidade (a partir do SQL Server 2005 também) que é utilizar as chamadas Functions CLR (programadas em C# por exemplo). O por quê? Porque operações em strings são custosas para o SQL Server, então uma função CLR poderia se comportar de maneira muito interessante (performática) neste caso.

Também não sabe o que é CLR ou como funciona? Então aguarde os próximos posts também!

Mas eu ainda continuo na esperança de algum dia termos isso diretamente no SQL Server, de uma maneira mais otimizada. :)

Abraços,

Thiago Zavaschi