SQL, Pomocnicza tabela liczb

Heh... przepraszam, że tak późno odpowiadam na stary post. I tak, musiałem odpowiedzieć, ponieważ najpopularniejszą odpowiedzią (w tamtym czasie Rekursywna odpowiedź CTE z linkiem do 14 różnych metod) w tym wątku jest, hmm... wydajność w najlepszym razie zagrożona.

Po pierwsze, artykuł z 14 różnymi rozwiązaniami jest dobry, aby zobaczyć różne metody tworzenia tabeli Liczby/Policzenia w locie, ale jak wskazano w artykule i cytowanym wątku, jest bardzo ważny cytat...

„sugestie dotyczące wydajności i wydajności są często subiektywne. Niezależnie od tego, w jaki sposób zapytanie jest używane, fizyczna implementacja określa wydajność zapytania. Dlatego zamiast polegać na tendencyjnych wskazówkach, konieczne jest przetestowanie zapytania i określenie, które z nich działa lepiej”.

Jak na ironię, sam artykuł zawiera wiele subiektywnych stwierdzeń i „stronniczych wskazówek”, takich jak „rekurencyjne CTE może generować wykaz numerów dość skutecznie i „To skuteczna metoda używania pętli WHILE z postu na grupie dyskusyjnego autorstwa Itzika Ben-Gen" (które, jestem pewien, zamieścił tylko w celach porównawczych). Chodźcie ludzie... Samo wspomnienie dobrego imienia Itzika może sprawić, że jakiś biedny gnojek faktycznie użyje tej okropnej metody. Autor powinien przećwiczyć to, co głosi, i powinien przeprowadzić trochę testów wydajności, zanim wyda takie absurdalnie niepoprawne stwierdzenia, zwłaszcza w obliczu jakiejkolwiek skalowalności.

Z myślą o przeprowadzeniu testów przed wypowiedzeniem subiektywnych stwierdzeń na temat tego, co robi kod lub co ktoś „lubi”, oto kod, z którym możesz przeprowadzić własne testy. Skonfiguruj profiler dla identyfikatora SPID, z którego przeprowadzasz test, i sprawdź go sam... po prostu wykonaj "Search'n'Replace" liczby 1000000 dla swojego "ulubionego" numeru i zobacz...

--===== 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

Skoro już przy tym jesteśmy, oto liczby, które otrzymuję z SQL Profiler dla wartości 100, 1000, 10000, 100000 i 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

Jak widać, metoda rekursywnego CTE jest drugą najgorszą tylko pętlą While dla czasu trwania i procesora i ma 8-krotnie większe obciążenie pamięci w postaci odczytów logicznych niż pętla While Loop . Jest to RBAR na sterydach i należy go unikać za wszelką cenę w przypadku obliczeń pojedynczego wiersza, podobnie jak należy unikać pętli While. Są miejsca, w których rekurencja jest dość cenna, ale to NIE JEST jednym z nich .

Jako pasek boczny, pan Denny jest absolutnie na miejscu... właściwie dobrana stała tabela liczb lub Tally to sposób na większość rzeczy. Co oznacza odpowiedni rozmiar? Cóż, większość ludzi używa tabeli Tally do generowania dat lub robienia podziałów na VARCHAR(8000). Jeśli utworzysz 11 000 wierszy tabeli Tally z poprawnym indeksem klastrowym na „N”, będziesz miećwystarczająco wierszy, aby utworzyćdaty o wartości przekraczającej 30 lat (pracuję trochę z hipotekami, więc 30 lat jest dla mnie kluczowąliczbą ) iz pewnością wystarczy, aby obsłużyć podział VARCHAR(8000). Dlaczego „właściwy rozmiar” jest tak ważny? Jeśli tabela Tally jest często używana, łatwo mieści się w pamięci podręcznej, co czyni ją niesamowicie szybką bez nadmiernego obciążania pamięci.

Wreszcie, co nie mniej ważne, każdy wie, że jeśli utworzysz stałą tabelę Tally, nie ma większego znaczenia, jakiej metody użyjesz do jej zbudowania, ponieważ 1) zostanie ona wykonana tylko raz i 2) jeśli jest to coś w rodzaju 11 000 wierszy tabeli, wszystkie metody będą działać „wystarczająco dobrze”. Skąd więc te wszystkie wzburzenia z mojej strony dotyczące tego, której metody użyć???

Odpowiedź jest taka, że jakiś biedak/dziewczyna, który nie wie nic lepszego i po prostu musi wykonać swoją pracę, może zobaczyć coś takiego jak metoda Rekursywnego CTE i zdecydować się na użycie jej do czegoś znacznie większego i znacznie częściej używanego niż budowanie stałą tabelę Tally i staram się chronić tych ludzi, serwery, na których działa ich kod, oraz firmę, która jest właścicielem danych na tych serwerach . Tak... to wielka sprawa. Powinno to być również dla wszystkich innych. Ucz właściwego sposobu robienia rzeczy zamiast „wystarczająco dobrego”. Zrób kilka testów przed opublikowaniem lub użyciem czegoś z posta lub książki... życie, które uratujesz, może w rzeczywistości być twoim własnym, zwłaszcza jeśli uważasz, że rekurencyjne CTE jest sposobem na coś takiego.;-)

Dzięki za wysłuchanie...