SQL, table auxiliaire de nombres
https://stackoverflow.com/questions/10819
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Pour certains types de requêtes SQL, une table de nombres auxiliaire peut être très utile.Il peut être créé sous forme de table avec autant de lignes dont vous avez besoin pour une tâche particulière ou sous forme de fonction définie par l'utilisateur qui renvoie le nombre de lignes requises dans chaque requête.
Quelle est la manière optimale de créer une telle fonction ?
La solution
Il h...désolé, je réponds si tard à un ancien message.Et oui, je devais répondre parce que la réponse la plus populaire (à l'époque, la réponse CTE récursive avec le lien vers 14 méthodes différentes) sur ce fil est, euh...performances au mieux contestées.
Premièrement, l'article avec les 14 solutions différentes est parfait pour voir les différentes méthodes de création d'un tableau Numbers/Tally à la volée, mais comme indiqué dans l'article et dans le fil de discussion cité, il existe un très citation importante....
«Les suggestions concernant l'efficacité et les performances sont souvent subjectives.Quelle que soit la façon dont une requête est utilisée, la mise en œuvre physique détermine l'efficacité d'une requête.Par conséquent, plutôt que de s'appuyer sur des directives biaisées, il est impératif que vous testiez la requête et déterminez lequel fonctionne mieux. "
Ironiquement, l'article lui-même contient de nombreuses déclarations subjectives et des « lignes directrices biaisées » telles que "un CTE récursif peut générer une liste de numéros assez efficacement" et "C'est une méthode efficace d'utiliser la boucle WHILE à partir d'une publication d'un groupe de discussion par Itzik Ben-Gen" (que je suis sûr qu'il a posté juste à des fins de comparaison).Allez les amis...Le simple fait de mentionner la bonne réputation d'Itzik pourrait inciter un pauvre plouc à utiliser cette horrible méthode.L'auteur devrait mettre en pratique ce qu'il prêche et devrait faire quelques tests de performances avant de faire des déclarations aussi ridiculement incorrectes, en particulier face à toute évolutivité.
Dans l'idée de faire des tests avant de faire des déclarations subjectives sur ce que fait un code ou sur ce que quelqu'un "aime", voici un code avec lequel vous pouvez faire vos propres tests.Configurez le profileur pour le SPID à partir duquel vous exécutez le test et vérifiez-le par vous-même...faites simplement un "Search'n'Replace" du numéro 1000000 pour votre numéro "favori" et voyez...
--===== 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
Pendant que nous y sommes, voici les chiffres que j'obtiens de SQL Profiler pour les valeurs de 100, 1 000, 10 000, 100 000 et 1 000 000...
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
Comme vous pouvez le voir, la méthode CTE récursive est la deuxième pire après la boucle While pour la durée et le processeur et a 8 fois la pression mémoire sous forme de lectures logiques que la boucle While.Il s'agit d'un RBAR sous stéroïdes et doit être évité à tout prix pour tout calcul sur une seule ligne, tout comme une boucle While doit être évitée. Il y a des endroits où la récursivité est très utile, mais celui-ci n'en fait PAS partie..
En guise de barre latérale, M.Denny est absolument parfait...une table de nombres ou de pointage permanente de taille correcte est la voie à suivre pour la plupart des choses.Que signifie correctement dimensionné ?Eh bien, la plupart des gens utilisent une table Tally pour générer des dates ou pour effectuer des fractionnements sur VARCHAR(8000).Si vous créez une table de comptage de 11 000 lignes avec l'index clusterisé correct sur "N", vous aurez suffisamment de lignes pour créer plus de 30 ans de dates (je travaille pas mal avec des prêts hypothécaires, donc 30 ans est un chiffre clé pour moi ) et certainement suffisant pour gérer une division VARCHAR(8000).Pourquoi la « bonne taille » est-elle si importante ?Si la table Tally est beaucoup utilisée, elle se glisse facilement dans le cache, ce qui la rend extrêmement rapide sans trop de pression sur la mémoire.
Enfin et surtout, tout le monde sait que si vous créez une table Tally permanente, la méthode que vous utilisez pour la construire n'a pas beaucoup d'importance car 1) elle ne sera créée qu'une seule fois et 2) si elle ressemble à une ligne de 11 000 lignes. table, toutes les méthodes vont fonctionner "assez bien". Alors pourquoi toute cette indignation de ma part sur la méthode à utiliser ???
La réponse est qu'un pauvre gars/fille qui ne sait pas mieux et qui a juste besoin de faire son travail pourrait voir quelque chose comme la méthode CTE récursive et décider de l'utiliser pour quelque chose de beaucoup plus grand et beaucoup plus fréquemment utilisé que la construction. une table Tally permanente et j'essaie de protéger ces personnes, les serveurs sur lesquels leur code s'exécute et l'entreprise qui possède les données sur ces serveurs.Ouais...c'est si grave.Cela devrait l’être aussi pour tout le monde.Enseignez la bonne façon de faire les choses au lieu de « assez bien ».Faites quelques tests avant de publier ou d'utiliser quelque chose d'un article ou d'un livre...la vie que vous sauvez peut, en fait, être la vôtre, surtout si vous pensez qu'un CTE récursif est la voie à suivre pour quelque chose comme ça.;-)
Merci pour l'écoute...
Autres conseils
La fonction la plus optimale serait d'utiliser un tableau au lieu d'une fonction.L'utilisation d'une fonction entraîne une charge CPU supplémentaire pour créer les valeurs des données renvoyées, surtout si les valeurs renvoyées couvrent une très large plage.
Cet article donne 14 solutions possibles différentes avec une discussion de chacune.Le point important est que :
Les suggestions concernant l'efficacité et les performances sont souvent subjectives.Quelle que soit la façon dont une requête est utilisée, la mise en œuvre physique détermine l'efficacité d'une requête.Par conséquent, plutôt que de s'appuyer sur des directives biaisées, il est impératif que vous testiez la requête et déterminez lequel fonctionne mieux.
Personnellement, j'ai aimé :
WITH Nbrs ( n ) AS (
SELECT 1 UNION ALL
SELECT 1 + n FROM Nbrs WHERE n < 500 )
SELECT n FROM Nbrs
OPTION ( MAXRECURSION 500 )
Cette vue est super rapide et contient tous les points positifs int valeurs.
CREATE VIEW dbo.Numbers
WITH SCHEMABINDING
AS
WITH Int1(z) AS (SELECT 0 UNION ALL SELECT 0)
, Int2(z) AS (SELECT 0 FROM Int1 a CROSS JOIN Int1 b)
, Int4(z) AS (SELECT 0 FROM Int2 a CROSS JOIN Int2 b)
, Int8(z) AS (SELECT 0 FROM Int4 a CROSS JOIN Int4 b)
, Int16(z) AS (SELECT 0 FROM Int8 a CROSS JOIN Int8 b)
, Int32(z) AS (SELECT TOP 2147483647 0 FROM Int16 a CROSS JOIN Int16 b)
SELECT ROW_NUMBER() OVER (ORDER BY z) AS n
FROM Int32
GO
En utilisant SQL Server 2016+ pour générer une table de nombres, vous pouvez utiliser OPENJSON :
-- range from 0 to @max - 1
DECLARE @max INT = 40000;
SELECT rn = CAST([key] AS INT)
FROM OPENJSON(CONCAT('[1', REPLICATE(CAST(',1' AS VARCHAR(MAX)),@max-1),']'));
Idée tirée de Comment pouvons-nous utiliser OPENJSON pour générer des séries de nombres ?
modifier:voir le commentaire de Conrad ci-dessous.
La réponse de Jeff Moden est excellente...mais je trouve sur Postgres que la méthode Itzik échoue à moins que vous ne supprimiez la ligne E32.
Un peu plus rapide sur Postgres (40 ms contre 100 ms) est une autre méthode que j'ai trouvée sur ici adapté pour postgres :
WITH
E00 (N) AS (
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 ),
E01 (N) AS (SELECT a.N FROM E00 a CROSS JOIN E00 b),
E02 (N) AS (SELECT a.N FROM E01 a CROSS JOIN E01 b ),
E03 (N) AS (SELECT a.N FROM E02 a CROSS JOIN E02 b
LIMIT 11000 -- end record 11,000 good for 30 yrs dates
), -- max is 100,000,000, starts slowing e.g. 1 million 1.5 secs, 2 mil 2.5 secs, 3 mill 4 secs
Tally (N) as (SELECT row_number() OVER (ORDER BY a.N) FROM E03 a)
SELECT N
FROM Tally
Alors que je passe de SQL Server au monde Postgres, j'ai peut-être manqué une meilleure façon de créer des tableaux de pointage sur cette plate-forme...ENTIER()?SÉQUENCE()?
Encore beaucoup plus tard, j'aimerais contribuer à un CTE « traditionnel » légèrement différent (ne touche pas aux tables de base pour obtenir le volume des lignes) :
--===== Hans CROSS JOINED CTE method
WITH Numbers_CTE (Digit)
AS
(SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9)
SELECT HundredThousand.Digit * 100000 + TenThousand.Digit * 10000 + Thousand.Digit * 1000 + Hundred.Digit * 100 + Ten.Digit * 10 + One.Digit AS Number
INTO #Tally5
FROM Numbers_CTE AS One CROSS JOIN Numbers_CTE AS Ten CROSS JOIN Numbers_CTE AS Hundred CROSS JOIN Numbers_CTE AS Thousand CROSS JOIN Numbers_CTE AS TenThousand CROSS JOIN Numbers_CTE AS HundredThousand
Ce CTE effectue plus de LECTURES que le CTE d'Itzik mais moins que le CTE traditionnel.Cependant, il effectue systématiquement moins d'ÉCRITURE que les autres requêtes.Comme vous le savez, les écritures sont systématiquement beaucoup plus chères que les lectures.
La durée dépend fortement du nombre de cœurs (MAXDOP) mais, sur mon 8 cœurs, s'exécute systématiquement plus rapidement (moins de durée en ms) que les autres requêtes.
J'utilise:
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
sur Windows Server 2012 R2, 32 Go, Xeon X3450 à 2,67 Ghz, 4 cœurs HT activés.
