Grundläggande om tabelluttryck, del 6 – Rekursiva CTE:er

Det som gör en medlem rekursiv är att ha en referens till CTE-namnet. Denna referens representerar den senaste exekveringens resultatuppsättning. I den första exekveringen av den rekursiva medlemmen representerar referensen till CTE-namnet ankarmedlemmens resultatuppsättning. I den N:e exekveringen, där N> 1, representerar referensen till CTE-namnet resultatuppsättningen av (N – 1) exekveringen av den rekursiva medlemmen. Som nämnts, när den rekursiva medlemmen returnerar en tom uppsättning, exekveras den inte igen. En hänvisning till CTE-namnet i den yttre frågan representerar de förenade resultatuppsättningarna av den enda exekveringen av ankarmedlemmen och alla exekveringen av den rekursiva medlemmen.

Följande kod implementerar den ovannämnda uppgiften att returnera underträdet av anställda för en given ingångshanterare, och skickar medarbetar-ID 3 som rotanställd i detta exempel:

DECLARE @root AS INT = 3;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname
FROM C;

Ankarfrågan exekveras endast en gång, och returnerar raden för den ingående rotanställda (anställd 3 i vårt fall).

Den rekursiva frågan förenar uppsättningen anställda från den tidigare nivån – representerad av referensen till CTE-namnet, alias som M för chefer – med deras direkta underordnade från tabellen Anställda, alias som S för underordnade. Join-predikatet är S.mgrid =M.empid, vilket betyder att den underordnades mgrid-värde är lika med chefens empid-värde. Den rekursiva frågan exekveras fyra gånger enligt följande:

1. Returnera underordnade till anställd 3; output:anställd 7
2. Returnera underordnade till anställd 7; output:anställda 9 och 11
3. Returnera underordnade till anställda 9 och 11; utgång:12, 13 och 14
4. Returnera underordnade till anställda 12, 13 och 14; output:tom set; rekursionen stannar

Referensen till CTE-namnet i den yttre frågan representerar de enhetliga resultaten av den enda exekveringen av ankarfrågan (anställd 3) med resultaten av alla exekveringar av den rekursiva frågan (anställda 7, 9, 11, 12, 13 och 14). Denna kod genererar följande utdata:

empid  mgrid  empname
------ ------ --------
3      1      Ina
7      3      Aaron
9      7      Rita
11     7      Gabriel
12     9      Emilia
13     9      Michael
14     9      Didi

Ett vanligt problem i programmeringslösningar är skenande kod som oändliga loopar som vanligtvis orsakas av en bugg. Med rekursiva CTE:er kan en bugg leda till att den rekursiva medlemmen körs på startbanan. Anta till exempel att du i vår lösning för att returnera underordnade till en ingående anställd hade en bugg i den rekursiva medlemmens join-predikat. Istället för att använda ON S.mgrid =M.empid, använde du ON S.mgrid =S.mgrid, så här:

DECLARE @root AS INT = 3;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = S.mgrid
)
SELECT empid, mgrid, empname
FROM C;

Med tanke på minst en anställd med ett icke-null manager-ID som finns i tabellen, kommer exekveringen av den rekursiva medlemmen att fortsätta att returnera ett icke-tomt resultat. Kom ihåg att det implicita uppsägningsvillkoret för den rekursiva medlemmen är när dess exekvering returnerar en tom resultatuppsättning. Om den returnerar en icke-tom resultatuppsättning, kör SQL Server den igen. Du inser att om SQL Server inte hade en mekanism för att begränsa de rekursiva körningarna, skulle den bara fortsätta att köra den rekursiva medlemmen upprepade gånger för alltid. Som en säkerhetsåtgärd stöder T-SQL ett MAXRECURSION-frågealternativ som begränsar det maximalt tillåtna antalet exekveringar av den rekursiva medlemmen. Som standard är denna gräns inställd på 100, men du kan ändra den till valfritt icke-negativt SMALLINT-värde, där 0 representerar ingen gräns. Att sätta den maximala rekursionsgränsen till ett positivt värde N innebär att N + 1 försök att utföra den rekursiva medlemmen avbryts med ett fel. Att till exempel köra ovanstående buggykod som den är innebär att du litar på standardgränsen för max rekursion på 100, så 101-körningen av den rekursiva medlemmen misslyckas:

empid  mgrid  empname
------ ------ --------
3      1      Ina
2      1      Eitan
3      1      Ina
...

Säg att i din organisation är det säkert att anta att medarbetarhierarkin inte kommer att överstiga 6 ledningsnivåer. Du kan minska den maximala rekursionsgränsen från 100 till ett mycket mindre antal, till exempel 10 för att vara på den säkra sidan, så här:

DECLARE @root AS INT = 3;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = S.mgrid
)
SELECT empid, mgrid, empname
FROM C
OPTION (MAXRECURSION 10);

Om det nu finns en bugg som resulterar i en körning av den rekursiva medlemmen, kommer den att upptäckas vid 11 försök att köra den rekursiva medlemmen istället för vid 101 exekvering:

empid  mgrid  empname
------ ------ --------
3      1      Ina
2      1      Eitan
3      1      Ina
...

Det är viktigt att notera att maxrekursionsgränsen främst bör användas som en säkerhetsåtgärd för att avbryta exekveringen av buggy runaway-kod. Kom ihåg att när gränsen överskrids avbryts exekveringen av koden med ett fel. Du bör inte använda det här alternativet för att begränsa antalet nivåer att besöka i filtreringssyfte. Du vill inte att ett fel ska genereras när det inte finns några problem med koden.

I filtreringssyfte kan du begränsa antalet nivåer som ska besökas programmatiskt. Du definierar en kolumn som heter lvl som spårar nivånumret för den nuvarande anställde jämfört med den ingående rotanställda. I ankarfrågan ställer du in lvl-kolumnen till konstanten 0. I den rekursiva frågan ställer du in den till chefens lvl-värde plus 1. För att filtrera så många nivåer under ingångsroten som @maxlevel, lägg till predikatet M.lvl <@ maxlevel till ON-satsen i den rekursiva frågan. Till exempel returnerar följande kod anställd 3 och två nivåer av underordnade till anställd 3:

DECLARE @root AS INT = 3, @maxlevel AS INT = 2;
 
WITH C AS
(
  SELECT empid, mgrid, empname, 0 AS lvl
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname, M.lvl + 1 AS lvl
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
      AND M.lvl < @maxlevel
)
SELECT empid, mgrid, empname, lvl
FROM C;

Den här frågan genererar följande utdata:

empid  mgrid  empname  lvl
------ ------ -------- ----
3      1      Ina      0
7      3      Aaron    1
9      7      Rita     2
11     7      Gabriel  2

Standard SEARCH och CYCLE satser

ISO/IEC SQL-standarden definierar två mycket kraftfulla alternativ för rekursiva CTE:er. En är en sats som kallas SEARCH som styr den rekursiva sökordningen, och en annan är en sats som heter CYCLE som identifierar cykler i de korsade banorna. Här är standardsyntaxen för de två satserna:

Funktion

Ange genereringen av ordnings- och cykeldetekteringsinformation i resultatet av rekursiva frågeuttryck.

Format

::=
[ ]
AS [ ]
::=
| |
::=
SÖK SET
::=
DEPTH FIRST BY | BREDD FIRST BY
::=
::=
CYKEL SET TILL
STANDARD ANVÄNDA
::= [ { }... ]
::=
::=
::=
::=
::=

I skrivande stund stöder inte T-SQL dessa alternativ, men i följande länkar kan du hitta förfrågningar om funktionsförbättringar som ber om att de ska inkluderas i T-SQL i framtiden och rösta på dem:

• Lägg till stöd för ISO/IEC SQL SEARCH-sats till rekursiva CTE:er i T-SQL
• Lägg till stöd för ISO/IEC SQL CYCLE-sats till rekursiva CTE:er i T-SQL

I följande avsnitt kommer jag att beskriva de två standardalternativen och även tillhandahålla logiskt likvärdiga alternativa lösningar som för närvarande är tillgängliga i T-SQL.

SÖK-sats

Standardsatsen SEARCH definierar den rekursiva sökordningen som BREADTH FIRST eller DEPTH FIRST med en eller flera specificerade ordningskolumner, och skapar en ny sekvenskolumn med ordningspositionerna för de besökta noderna. Du anger BREADTH FIRST för att söka först över varje nivå (bredd) och sedan nedåt i nivåerna (djup). Du anger DEPTH FIRST för att söka först ner (djup) och sedan tvärs över (bredd).

Du anger SEARCH-satsen precis före den yttre frågan.

Jag börjar med ett exempel för bredd första rekursiva sökordning. Kom bara ihåg att den här funktionen inte är tillgänglig i T-SQL, så du kommer inte att kunna köra de exempel som använder standardklausulerna i SQL Server eller Azure SQL Database. Följande kod returnerar underträdet för anställd 1, ber om en bredd första sökorder efter empid, skapar en sekvenskolumn som kallas seqbreadth med ordningspositionerna för de besökta noderna:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
 
SEARCH BREADTH FIRST BY empid SET seqbreadth
--------------------------------------------
 
SELECT empid, mgrid, empname, seqbreadth
FROM C
ORDER BY seqbreadth;

Här är den önskade utmatningen av denna kod:

empid  mgrid  empname  seqbreadth
------ ------ -------- -----------
1      NULL   David    1
2      1      Eitan    2
3      1      Ina      3
4      2      Seraph   4
5      2      Jiru     5
6      2      Steve    6
7      3      Aaron    7
8      5      Lilach   8
9      7      Rita     9
10     5      Sean     10
11     7      Gabriel  11
12     9      Emilia   12
13     9      Michael  13
14     9      Didi     14

Bli inte förvirrad av det faktum att seqbreadth-värdena verkar vara identiska med empid-värdena. Det är bara en slump som ett resultat av det sätt som jag manuellt tilldelade empid-värdena i exempeldata som jag skapade.

Figur 2 har en grafisk skildring av anställdshierarkin, med en prickad linje som visar bredden i första ordningen i vilken noderna söktes. Empid-värdena visas precis under de anställdas namn, och de tilldelade seqbreadth-värdena visas i det nedre vänstra hörnet av varje ruta.

Figur 2:Sökbredden först

Vad som är intressant att notera här är att inom varje nivå söks noderna baserat på den specificerade kolumnordningen (empid i vårt fall) oavsett nodens moderförening. Lägg till exempel märke till att på den fjärde nivån nås Lilach först, Rita andra, Sean tredje och Gabriel sist. Det beror på att bland alla anställda på den fjärde nivån är det deras ordning baserat på deras empidvärden. Det är inte som att Lilach och Sean ska genomsökas i följd eftersom de är direkta underordnade till samma chef, Jiru.

Det är ganska enkelt att komma med en T-SQL-lösning som ger den logiska motsvarigheten till standardalternativet SAERCH DEPTH FIRST. Du skapar en kolumn som heter lvl som jag visade tidigare för att spåra nodens nivå med avseende på roten (0 för den första nivån, 1 för den andra, och så vidare). Sedan beräknar du den önskade resultatsekvenskolumnen i den yttre frågan med hjälp av en ROW_NUMBER-funktion. Som fönsterordning anger du först lvl och sedan önskad beställningskolumn (empid i vårt fall). Här är den fullständiga lösningens kod:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname, 0 AS lvl
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname, M.lvl + 1 AS lvl
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname,
  ROW_NUMBER() OVER(ORDER BY lvl, empid) AS seqbreadth
FROM C
ORDER BY seqbreadth;

Låt oss sedan undersöka sökordern DEPTH FIRST. Enligt standarden ska följande kod returnera underträdet för anställd 1, fråga efter en djup första sökorder efter empid, skapa en sekvenskolumn som kallas seqdepth med ordningspositionerna för de sökta noderna:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
 
SEARCH DEPTH FIRST BY empid SET seqdepth
----------------------------------------
 
SELECT empid, mgrid, empname, seqdepth
FROM C
ORDER BY seqdepth;

Följande är den önskade utmatningen av denna kod:

empid  mgrid  empname  seqdepth
------ ------ -------- ---------
1      NULL   David    1
2      1      Eitan    2
4      2      Seraph   3
5      2      Jiru     4
8      5      Lilach   5
10     5      Sean     6
6      2      Steve    7
3      1      Ina      8
7      3      Aaron    9
9      7      Rita     10
12     9      Emilia   11
13     9      Michael  12
14     9      Didi     13
11     7      Gabriel  14

När man tittar på den önskade frågeutgången är det förmodligen svårt att ta reda på varför sekvensvärdena tilldelades som de var. Bild 3 borde hjälpa. Den har en grafisk skildring av de anställdas hierarki, med en prickad linje som reflekterar djupets första sökorder, med de tilldelade sekvensvärdena i det nedre vänstra hörnet av varje ruta.

Figur 3:Sökdjup först

Att komma med en T-SQL-lösning som ger den logiska motsvarigheten till standardalternativet SEARCH DEPTH FIRST är lite knepigt, men ändå genomförbart. Jag kommer att beskriva lösningen i två steg.

I steg 1 beräknar du för varje nod en binär sorteringsväg som är gjord av ett segment per förfader till noden, där varje segment återspeglar sorteringspositionen för förfadern bland sina syskon. Du bygger den här vägen på samma sätt som du beräknar lvl-kolumnen. Det vill säga, börja med en tom binär sträng för rotnoden i ankarfrågan. Sedan, i den rekursiva frågan, sammanfogar du förälderns sökväg med nodens sorteringsposition bland syskon efter att du konverterat den till ett binärt segment. Du använder funktionen ROW_NUMBER för att beräkna positionen, partitionerad av föräldern (mgrid i vårt fall) och ordnad efter den relevanta ordningskolumnen (empid i vårt fall). Du konverterar radnumret till ett binärt värde av tillräcklig storlek beroende på det maximala antalet direkta barn som en förälder kan ha i din graf. BINARY(1) stöder upp till 255 barn per förälder, BINARY(2) stöder 65 535, BINARY(3):16 777 215, BINARY(4):4 294 967 295. I en rekursiv CTE måste motsvarande kolumner i ankaret och de rekursiva frågorna vara av samma typ och storlek , så se till att konvertera sorteringsvägen till ett binärt värde av samma storlek i båda.

Här är koden som implementerar steg 1 i vår lösning (förutsatt att BINARY(1) räcker per segment, vilket innebär att du inte har fler än 255 direkta underordnade per chef):

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname,
    CAST(0x AS VARBINARY(900)) AS sortpath
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname,
     CAST(M.sortpath
            + CAST(ROW_NUMBER() OVER(PARTITION BY S.mgrid ORDER BY S.empid)
                AS BINARY(1))
       AS VARBINARY(900)) AS sortpath
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname, sortpath
FROM C;

Denna kod genererar följande utdata:

empid  mgrid  empname  sortpath
------ ------ -------- -----------
1      NULL   David    0x
2      1      Eitan    0x01
3      1      Ina      0x02
7      3      Aaron    0x0201
9      7      Rita     0x020101
11     7      Gabriel  0x020102
12     9      Emilia   0x02010101
13     9      Michael  0x02010102
14     9      Didi     0x02010103
4      2      Seraph   0x0101
5      2      Jiru     0x0102
6      2      Steve    0x0103
8      5      Lilach   0x010201
10     5      Sean     0x010202

Observera att jag använde en tom binär sträng som sorteringsväg för rotnoden för det enda underträdet som vi frågar här. Om ankarmedlemmen potentiellt kan returnera flera underträdrötter, börja helt enkelt med ett segment som är baserat på en ROW_NUMBER-beräkning i ankarfrågan, på samma sätt som du beräknar den i den rekursiva frågan. I ett sådant fall blir din sorteringsväg ett segment längre.

Vad som återstår att göra i steg 2, är att skapa den önskade resultatets sek-djupskolumnen genom att beräkna radnummer som är sorterade efter sorteringsväg i den yttre frågan, som så

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname,
    CAST(0x AS VARBINARY(900)) AS sortpath
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname,
     CAST(M.sortpath
            + CAST(ROW_NUMBER() OVER(PARTITION BY S.mgrid ORDER BY S.empid)
                AS BINARY(1))
       AS VARBINARY(900)) AS sortpath
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname,
  ROW_NUMBER() OVER(ORDER BY sortpath) AS seqdepth
FROM C
ORDER BY seqdepth;

Denna lösning är den logiska motsvarigheten till att använda standardalternativet SEARCH DEPTH FIRST som visats tidigare tillsammans med dess önskade utdata.

När du väl har en sekvenskolumn som återspeglar djupets första sökordning (seqdepth i vårt fall), med bara lite mer ansträngning kan du skapa en mycket snygg visuell skildring av hierarkin. Du kommer också att behöva den tidigare nämnda lvl-kolumnen. Du beställer den yttre frågan efter sekvenskolumnen. Du returnerar något attribut som du vill använda för att representera noden (säg, empname i vårt fall), med prefix av någon sträng (säg ' | ') replikerade lvl gånger. Här är den fullständiga koden för att uppnå en sådan visuell skildring:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, empname, 0 AS lvl,
    CAST(0x AS VARBINARY(900)) AS sortpath
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.empname, M.lvl + 1 AS lvl,
     CAST(M.sortpath
            + CAST(ROW_NUMBER() OVER(PARTITION BY S.mgrid ORDER BY S.empid)
                AS BINARY(1))
       AS VARBINARY(900)) AS sortpath
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid,
  ROW_NUMBER() OVER(ORDER BY sortpath) AS seqdepth,
  REPLICATE(' | ', lvl) + empname AS emp
FROM C
ORDER BY seqdepth;

Denna kod genererar följande utdata:

empid  seqdepth  emp
------ --------- --------------------
1      1         David
2      2          | Eitan
4      3          |  | Seraph
5      4          |  | Jiru
8      5          |  |  | Lilach
10     6          |  |  | Sean
6      7          |  | Steve
3      8          | Ina
7      9          |  | Aaron
9      10         |  |  | Rita
12     11         |  |  |  | Emilia
13     12         |  |  |  | Michael
14     13         |  |  |  | Didi
11     14         |  |  | Gabriel

Det är ganska coolt!

CYCLE-sats

Grafstrukturer kan ha cykler. Dessa cykler kan vara giltiga eller ogiltiga. Ett exempel på giltiga cykler är en graf som representerar motorvägar och vägar som förbinder städer och städer. Det är vad som kallas en cyklisk graf . Omvänt är det inte meningen att en graf som representerar en anställdshierarki som i vårt fall har cykler. Det är vad som kallas en acyklisk Graf. Anta dock att du på grund av någon felaktig uppdatering får en cykel oavsiktligt. Anta till exempel att du av misstag uppdaterar chefs-ID för VD (anställd 1) till anställd 14 genom att köra följande kod:

UPDATE Employees
  SET mgrid = 14
WHERE empid = 1;

Du har nu en ogiltig cykel i medarbetarhierarkin.

Oavsett om cykler är giltiga eller ogiltiga, när du korsar grafstrukturen, vill du verkligen inte fortsätta att följa en cyklisk väg upprepade gånger. I båda fallen vill du sluta följa en väg när en icke-första förekomst av samma nod hittas, och markera en sådan väg som cyklisk.

Så vad händer när du frågar en graf som har cykler med hjälp av en rekursiv fråga, utan någon mekanism på plats för att upptäcka dessa? Detta beror på genomförandet. I SQL Server kommer du någon gång att nå den maximala rekursionsgränsen och din fråga kommer att avbrytas. Om du till exempel antar att du körde ovanstående uppdatering som introducerade cykeln, prova att köra följande rekursiva fråga för att identifiera underträdet för anställd 1:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname
FROM C;

Eftersom den här koden inte anger en explicit maxrekursionsgräns, antas standardgränsen på 100. SQL Server avbryter exekveringen av denna kod innan den är klar och genererar ett fel:

empid  mgrid  empname
------ ------ --------
1      14     David
2      1      Eitan
3      1      Ina
7      3      Aaron
9      7      Rita
11     7      Gabriel
12     9      Emilia
13     9      Michael
14     9      Didi
1      14     David
2      1      Eitan
3      1      Ina
7      3      Aaron
...

SQL-standarden definierar en sats som kallas CYCLE för rekursiva CTE:er, vilket gör att du kan hantera cykler i din graf. Du anger denna sats precis före den yttre frågan. Om en SEARCH-sats också finns anger du den först och sedan CYCLE-satsen. Här är syntaxen för CYCLE-satsen:

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
 
CYCLE empid SET cycle TO 1 DEFAULT 0
------------------------------------
 
SELECT empid, mgrid, empname
FROM C;

empid  mgrid  empname  cycle
------ ------ -------- ------
1      14     David    0
2      1      Eitan    0
3      1      Ina      0
7      3      Aaron    0
9      7      Rita     0
11     7      Gabriel  0
12     9      Emilia   0
13     9      Michael  0
14     9      Didi     0
1      14     David    1
4      2      Seraph   0
5      2      Jiru     0
6      2      Steve    0
8      5      Lilach   0
10     5      Sean     0

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname,
    CAST('.' + CAST(empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname,
    CAST(M.ancpath + CAST(S.empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname, ancpath
FROM C;

empid  mgrid  empname  ancpath
------ ------ -------- -------------------
1      14     David    .1.
2      1      Eitan    .1.2.
3      1      Ina      .1.3.
7      3      Aaron    .1.3.7.
9      7      Rita     .1.3.7.9.
11     7      Gabriel  .1.3.7.11.
12     9      Emilia   .1.3.7.9.12.
13     9      Michael  .1.3.7.9.13.
14     9      Didi     .1.3.7.9.14.
1      14     David    .1.3.7.9.14.1.
2      1      Eitan    .1.3.7.9.14.1.2.
3      1      Ina      .1.3.7.9.14.1.3.
7      3      Aaron    .1.3.7.9.14.1.3.7.
...

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname,
    CAST('.' + CAST(empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath,
    0 AS cycle
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname,
    CAST(M.ancpath + CAST(S.empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath,
    CASE WHEN M.ancpath LIKE '%.' + CAST(S.empid AS VARCHAR(4)) + '.%' THEN 1
      ELSE 0 END AS cycle
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
)
SELECT empid, mgrid, empname, ancpath, cycle
FROM C;

empid  mgrid  empname  ancpath             cycle
------ ------ -------- ------------------- ------
1      14     David    .1.                 0
2      1      Eitan    .1.2.               0
3      1      Ina      .1.3.               0
7      3      Aaron    .1.3.7.             0
9      7      Rita     .1.3.7.9.           0
11     7      Gabriel  .1.3.7.11.          0
12     9      Emilia   .1.3.7.9.12.        0
13     9      Michael  .1.3.7.9.13.        0
14     9      Didi     .1.3.7.9.14.        0
1      14     David    .1.3.7.9.14.1.      1
2      1      Eitan    .1.3.7.9.14.1.2.    0
3      1      Ina      .1.3.7.9.14.1.3.    1
7      3      Aaron    .1.3.7.9.14.1.3.7.  1
...

DECLARE @root AS INT = 1;
 
WITH C AS
(
  SELECT empid, mgrid, empname,
    CAST('.' + CAST(empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath,
    0 AS cycle
  FROM dbo.Employees
  WHERE empid = @root
 
  UNION ALL
 
  SELECT S.empid, S.mgrid, S.empname,
    CAST(M.ancpath + CAST(S.empid AS VARCHAR(4)) + '.' AS VARCHAR(900)) AS ancpath,
    CASE WHEN M.ancpath LIKE '%.' + CAST(S.empid AS VARCHAR(4)) + '.%' THEN 1
      ELSE 0 END AS cycle
  FROM C AS M
    INNER JOIN dbo.Employees AS S
      ON S.mgrid = M.empid
      AND M.cycle = 0
)
SELECT empid, mgrid, empname, cycle
FROM C;

empid  mgrid  empname  cycle
------ ------ -------- -----------
1      14     David    0
2      1      Eitan    0
3      1      Ina      0
7      3      Aaron    0
9      7      Rita     0
11     7      Gabriel  0
12     9      Emilia   0
13     9      Michael  0
14     9      Didi     0
1      14     David    1
4      2      Seraph   0
5      2      Jiru     0
6      2      Steve    0
8      5      Lilach   0
10     5      Sean     0

UPDATE Employees
  SET mgrid = NULL
WHERE empid = 1;