Heh... sorry dat ik zo laat reageer op een oud bericht. En ja, ik moest reageren omdat het meest populaire antwoord (destijds het recursieve CTE-antwoord met de link naar 14 verschillende methoden) in deze thread is, ummm... prestaties op zijn best uitgedaagd.
Ten eerste is het artikel met de 14 verschillende oplossingen prima om de verschillende methoden voor het maken van een Numbers/Tally-tabel in een oogwenk te zien, maar zoals aangegeven in het artikel en in de geciteerde thread, is er een zeer belangrijk citaat...
"suggesties met betrekking tot efficiëntie en prestaties zijn vaak subjectief. Ongeacht hoe een query wordt gebruikt, de fysieke implementatie bepaalt de efficiëntie van een query. Daarom is het absoluut noodzakelijk dat u de query test en bepaalt welke beter presteert."
Ironisch genoeg bevat het artikel zelf veel subjectieve uitspraken en "bevooroordeelde richtlijnen" zoals "een recursieve CTE kan een nummervermelding vrij efficiënt genereren " en "Dit is een efficiënte methode van het gebruik van een WHILE-lus van een bericht in een nieuwsgroep door Itzik Ben-Gen" (waarvan ik zeker weet dat hij het alleen voor vergelijkingsdoeleinden heeft gepost). Kom op mensen... Alleen al het noemen van Itzik's goede naam kan een arme slons ertoe brengen die afschuwelijke methode daadwerkelijk te gebruiken. De auteur moet oefenen wat hij predikt en een beetje prestatietesten doen voordat hij zulke belachelijk onjuiste uitspraken doet, vooral in het licht van enige schaalbaarheid.
Met de gedachte om daadwerkelijk wat te testen voordat je subjectieve beweringen doet over wat een code doet of wat iemand "leuk" vindt, is hier wat code waarmee je je eigen tests kunt doen. Stel profiler in voor de SPID van waaruit je de test uitvoert en bekijk het zelf... doe gewoon een "Search'n'Replace" van het nummer 1000000 voor je "favoriete" nummer en zie...
--===== 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
Nu we toch bezig zijn, hier zijn de cijfers die ik krijg van SQL Profiler voor de waarden 100, 1000, 10000, 100000 en 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
Zoals u kunt zien, is de recursieve CTE-methode de op één na slechtste, alleen voor de While-lus voor duur en CPU en heeft 8 keer meer geheugendruk in de vorm van logische uitlezingen dan de While-lus . Het is RBAR op steroïden en moet koste wat kost worden vermeden voor berekeningen met één rij, net zoals een While-lus moet worden vermeden. Er zijn plaatsen waar recursie behoorlijk waardevol is, maar dit IS er niet een van .
Als zijbar is Mr. Denny absoluut perfect... een permanente Numbers- of Tally-tafel van de juiste maat is de juiste keuze voor de meeste dingen. Wat betekent de juiste maat? Welnu, de meeste mensen gebruiken een Tally-tabel om datums te genereren of om splitsingen te maken op VARCHAR(8000). Als u een Tally-tabel met 11.000 rijen maakt met de juiste geclusterde index op "N", heeft u genoeg rijen om datums van meer dan 30 jaar te maken (ik werk nogal wat met hypotheken, dus 30 jaar is een sleutelgetal voor mij ) en zeker genoeg om een VARCHAR(8000)-splitsing aan te kunnen. Waarom is "juiste maat" zo belangrijk? Als de Tally-tabel veel wordt gebruikt, past hij gemakkelijk in de cache, waardoor hij razendsnel is zonder al te veel geheugendruk.
Last but not least, iedereen weet dat als je een permanente Tally-tabel maakt, het niet veel uitmaakt welke methode je gebruikt om hem te bouwen, omdat 1) hij maar één keer wordt gemaakt en 2) als het zoiets is als een rij van 11.000 tabel, zullen alle methoden "goed genoeg" worden uitgevoerd. Dus waarom al die verontwaardiging van mijn kant over welke methode te gebruiken???
Het antwoord is dat een arme jongen/meid die niet beter weet en gewoon zijn of haar werk moet doen, iets als de recursieve CTE-methode kan zien en besluiten deze te gebruiken voor iets veel groters en veel vaker gebruikt dan bouwen een permanente Tally-tabel en ik probeer die mensen te beschermen, de servers waarop hun code draait en het bedrijf dat eigenaar is van de gegevens op die servers . Ja... het is zo'n groot probleem. Het zou ook voor alle anderen moeten gelden. Leer de juiste manier om dingen te doen in plaats van "goed genoeg". Doe wat tests voordat u iets uit een bericht of boek plaatst of gebruikt... het leven dat u redt, kan in feite van uzelf zijn, vooral als u denkt dat een recursieve CTE de juiste keuze is voor zoiets als dit.;-)
Bedankt voor het luisteren...