SQL, Hjælpetabel over tal

Heh... undskyld jeg er så sent på at svare på et gammelt indlæg. Og ja, jeg var nødt til at svare, fordi det mest populære svar (på det tidspunkt, det rekursive CTE-svar med link til 14 forskellige metoder) i denne tråd er, ummm... ydeevne udfordret i bedste fald.

For det første er artiklen med de 14 forskellige løsninger fint til at se de forskellige metoder til at oprette en tal-/optællingstabel på farten, men som påpeget i artiklen og i den citerede tråd, er der en meget vigtigt citat...

"forslag vedrørende effektivitet og ydeevne er ofte subjektive. Uanset hvordan en forespørgsel bruges, bestemmer den fysiske implementering effektiviteten af en forespørgsel. Derfor er det i stedet for at stole på uvildige retningslinjer, bydende nødvendigt, at du tester forespørgslen og afgør, hvilken der klarer sig bedst."

Ironisk nok indeholder artiklen i sig selv mange subjektive udsagn og "biased guidelines" såsom "en rekursiv CTE kan generere en nummerliste temmelig effektivt " og "Dette er en effektiv metode af at bruge WHILE-løkke fra et nyhedsgruppeindlæg af Itzik Ben-Gen" (som jeg er sikker på, at han postede kun for sammenligningsformål). Kom nu folkens... Bare det at nævne Itziks gode navn kan få nogle stakkels sludder til rent faktisk at bruge den forfærdelige metode. Forfatteren bør praktisere det, han prædiker, og bør lave en lille præstationstest, før han kommer med sådanne latterligt ukorrekte udsagn, især i lyset af enhver skalerbarhed.

Med tanken om rent faktisk at lave nogle test, før du fremsætter subjektive påstande om, hvad en kode gør, eller hvad nogen "kan lide", her er en kode, du kan lave din egen test med. Opsæt profiler for den SPID, du kører testen fra, og tjek det selv ud... bare lav en "Search'n'Replace" af nummeret 1000000 for dit "favorit"-nummer og se...

--===== Test for 1000000 rows ==================================
GO
--===== Traditional RECURSIVE CTE method
   WITH Tally (N) AS 
        ( 
         SELECT 1 UNION ALL 
         SELECT 1 + N FROM Tally WHERE N < 1000000 
        ) 
 SELECT N 
   INTO #Tally1 
   FROM Tally 
 OPTION (MAXRECURSION 0);
GO
--===== Traditional WHILE LOOP method
 CREATE TABLE #Tally2 (N INT);
    SET NOCOUNT ON;
DECLARE @Index INT;
    SET @Index = 1;
  WHILE @Index <= 1000000 
  BEGIN 
         INSERT #Tally2 (N) 
         VALUES (@Index);
            SET @Index = @Index + 1;
    END;
GO
--===== Traditional CROSS JOIN table method
 SELECT TOP (1000000)
        ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS N
   INTO #Tally3
   FROM Master.sys.All_Columns ac1
  CROSS JOIN Master.sys.ALL_Columns ac2;
GO
--===== Itzik's CROSS JOINED CTE method
   WITH E00(N) AS (SELECT 1 UNION ALL SELECT 1),
        E02(N) AS (SELECT 1 FROM E00 a, E00 b),
        E04(N) AS (SELECT 1 FROM E02 a, E02 b),
        E08(N) AS (SELECT 1 FROM E04 a, E04 b),
        E16(N) AS (SELECT 1 FROM E08 a, E08 b),
        E32(N) AS (SELECT 1 FROM E16 a, E16 b),
   cteTally(N) AS (SELECT ROW_NUMBER() OVER (ORDER BY N) FROM E32)
 SELECT N
   INTO #Tally4
   FROM cteTally
  WHERE N <= 1000000;
GO
--===== Housekeeping
   DROP TABLE #Tally1, #Tally2, #Tally3, #Tally4;
GO

Mens vi er i gang, er her tallene, jeg får fra SQL Profiler for værdierne 100, 1000, 10000, 100000 og 1000000...

SPID TextData                                 Dur(ms) CPU   Reads   Writes
---- ---------------------------------------- ------- ----- ------- ------
  51 --===== Test for 100 rows ==============       8     0       0      0
  51 --===== Traditional RECURSIVE CTE method      16     0     868      0
  51 --===== Traditional WHILE LOOP method CR      73    16     175      2
  51 --===== Traditional CROSS JOIN table met      11     0      80      0
  51 --===== Itzik's CROSS JOINED CTE method        6     0      63      0
  51 --===== Housekeeping   DROP TABLE #Tally      35    31     401      0

  51 --===== Test for 1000 rows =============       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method      47    47    8074      0
  51 --===== Traditional WHILE LOOP method CR      80    78    1085      0
  51 --===== Traditional CROSS JOIN table met       5     0      98      0
  51 --===== Itzik's CROSS JOINED CTE method        2     0      83      0
  51 --===== Housekeeping   DROP TABLE #Tally       6    15     426      0

  51 --===== Test for 10000 rows ============       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method     434   344   80230     10
  51 --===== Traditional WHILE LOOP method CR     671   563   10240      9
  51 --===== Traditional CROSS JOIN table met      25    31     302     15
  51 --===== Itzik's CROSS JOINED CTE method       24     0     192     15
  51 --===== Housekeeping   DROP TABLE #Tally       7    15     531      0

  51 --===== Test for 100000 rows ===========       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method    4143  3813  800260    154
  51 --===== Traditional WHILE LOOP method CR    5820  5547  101380    161
  51 --===== Traditional CROSS JOIN table met     160   140     479    211
  51 --===== Itzik's CROSS JOINED CTE method      153   141     276    204
  51 --===== Housekeeping   DROP TABLE #Tally      10    15     761      0

  51 --===== Test for 1000000 rows ==========       0     0       0      0
  51 --===== Traditional RECURSIVE CTE method   41349 37437 8001048   1601
  51 --===== Traditional WHILE LOOP method CR   59138 56141 1012785   1682
  51 --===== Traditional CROSS JOIN table met    1224  1219    2429   2101
  51 --===== Itzik's CROSS JOINED CTE method     1448  1328    1217   2095
  51 --===== Housekeeping   DROP TABLE #Tally       8     0     415      0

Som du kan se, er den rekursive CTE-metode kun den næstværste til While Loop for Duration og CPU og har 8 gange hukommelsestrykket i form af logiske læsninger end While Loop . Det er RBAR på steroider og bør undgås, for enhver pris, for enhver enkelt række beregninger ligesom en While Loop bør undgås. Der er steder, hvor rekursion er ret værdifuldt, men dette ER IKKE et af dem .

Som sidebjælke er Mr. Denny helt i top... et permanent tal- eller tal-bord i korrekt størrelse er vejen at gå til de fleste ting. Hvad betyder korrekt størrelse? Nå, de fleste bruger en Tally-tabel til at generere datoer eller til at lave opdelinger på VARCHAR(8000). Hvis du opretter en 11.000 rækker Tally-tabel med det korrekte klyngeindeks på "N", vil du have rækker nok til at oprette mere end 30 års datoer (jeg arbejder en del med realkreditlån, så 30 år er et nøgletal for mig ) og helt sikkert nok til at håndtere en VARCHAR(8000) split. Hvorfor er "rigtig størrelse" så vigtigt? Hvis Tally-bordet bliver brugt meget, passer det nemt i cachen, hvilket gør det lynhurtigt uden meget pres på hukommelsen overhovedet.

Sidst men ikke mindst ved alle, at hvis du opretter en permanent Tally-tabel, er det ikke meget ligegyldigt, hvilken metode du bruger til at bygge den, fordi 1) den kun bliver lavet én gang og 2) hvis den er noget i retning af en 11.000 række tabel, vil alle metoderne køre "godt nok". Så hvorfor al den indigination fra min side over, hvilken metode jeg skal bruge???

Svaret er, at en eller anden stakkels fyr/pige, der ikke ved bedre og bare skal have sit arbejde gjort, kan se noget som den rekursive CTE-metode og beslutte at bruge den til noget, der er meget større og meget hyppigere brugt end at bygge en permanent Tally-tabel, og jeg forsøger at beskytte disse personer, serverne deres kode kører på, og det firma, der ejer dataene på disse servere . Ja... det er så stor en sag. Det burde også være for alle andre. Lær den rigtige måde at gøre tingene på i stedet for "god nok". Udfør nogle test, før du poster eller bruger noget fra et indlæg eller en bog... det liv, du redder, kan faktisk være dit eget, især hvis du tror, at en rekursiv CTE er vejen at gå for sådan noget.;-)

Tak fordi du lyttede...