|
|
|
SSC-Insane
         
Group: General Forum Members
Last Login: Today @ 8:06 AM
Points: 21,630,
Visits: 27,486
|
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Yesterday @ 8:17 AM
Points: 4,804,
Visits: 8,074
|
|
Excellent article, Lynn! I'll make sure to include your oustanding UDF in my dev/production environment. I already have one that does the same thing, in a while loop . Thanks for this content, it will be very useful!
Get your two-cent-answer quickly The Spaghetti DBA
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Friday, February 15, 2013 7:29 AM
Points: 509,
Visits: 718
|
|
Top job Lynn.
It's this sort of article that really keeps me on my toes with respect to the SQL I write - there's almost always a better way, and this article has shown me a better way.
Really good explanation too. Thanks!
Atlantis Interactive - SQL Server Tools My blog Why I wrote a sql query analyzer clone
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 3:57 AM
Points: 288,
Visits: 1,903
|
|
I quickly read the article and ran no tests myself, but if all this code is only used to quickly fill a table with numbers then I am perplexed about the complexity as well as the amount of code. We all have seen so many 5 line SQL code solutions that do the same, be it only for tally table generation.
If the code is to dynamically generate a list of numbers in a desired range for immediate use in another statement I still find the code rather complex and would like to see comparisons with dozens of other tally solutions that can be found on this site. We all know by now that recursion is not the tool to use for this and to compare it with that doesn’t say much to me.
Don't take this the wrong way, but can you clarify to me what the exact intended use is and if you did compare it with similar solutions that are not rooted in recursion? I can see the range and order aspect as something novel compared to pure tally functions, but a function that simply reads a tally table could do the same in a single statment by using some basic math.
What required the many staged approach you took?
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, June 29, 2012 4:56 AM
Points: 163,
Visits: 427
|
|
I agree. Definitely an interesting article but I would have liked to see tests against an already created and indexed tally table and the reasons for going dynamic rather than static since it is quite easy to sort and scale results to any interval/order from a static table.
I'll have a look myself of course but for now cannot thing of a reason to use a function over a static tally table. Maybe I'm missing something though.
_______________________________________________________ Change is inevitable... Except from a vending machine.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 3:57 AM
Points: 288,
Visits: 1,903
|
|
Here is an exampe of generating a range of numbers form an existing tally table or function with numbers starting at 1.
-- Get a range of numbers based on a tally table, the range can be 20bits wide -- (1048576 positions) in this example. declare @min bigint, @max bigint; select @min = 1000000000, @max = 1000000200;
select top (@max - @min + 1) (@min - 1) + N from dbo.tally20b;
Even with a 12 bit tally table you can generate ranges of 4096 numbers at any position in the bigint range. Creating intervals is no more then adding a multiplyer (see below):
-- Get a range of numbers based on a tally table, the range can be 20bits wide -- (1048576 positions) in this example. An interval of 10 is used. declare @min bigint, @max bigint; select @min = 1000000000, @max = 1000000200;
select top (@max - @min + 1) @min + (10 * (N - 1)) from dbo.tally20b;
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 9:42 AM
Points: 2,891,
Visits: 5,858
|
|
Rob Fisk (9/22/2009) I agree. Definitely an interesting article but I would have liked to see tests against an already created and indexed tally table and the reasons for going dynamic rather than static since it is quite easy to sort and scale results to any interval/order from a static table.
I'll have a look myself of course but for now cannot thing of a reason to use a function over a static tally table. Maybe I'm missing something though.
I can't tell you the number of times a tally or numbers table approach has been suggested to someone on the forums here and the response was something to the affect of "I'm not allowed to change the schema" or "I can't get a static table like that approved." Seems like a quick way to dynamically generate a tally table of just the numbers you need would be very helpful in those circumstances...
Good thorough description of the code Lynn, and a good read.
Thanks, -Luke.
To help us help you read this
For better help with performance problems please read this
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, June 29, 2012 4:56 AM
Points: 163,
Visits: 427
|
|
Indeed, a very well written, descriptive and, as I said, interesting article. It's already been bookmarked so I can look at the interaction of the various elements in the code later since it seems they could help me with other things I have been looking at.
I had completely forgotten the scenario of being able to create functions but not tables. Especially if those tables have no impact on the rest of the schema. I must have been on some happy juice and forgotten what a crazy world wee live in.
_______________________________________________________ Change is inevitable... Except from a vending machine.
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 11:48 AM
Points: 32,
Visits: 132
|
|
I am a bit perplexed by the article. I buiul a tally table in each of my databases a couple of years ago. Static table, 100K rows, PK. When I initially built it I really did not care if it took 150ms or 1.3 seconds, because it was a one-time thing. A tally table is so useful, it should be part of the SQL installation and be included when a new database is created.
An article on how to use a tally table would have been a lot better than how to create one. Likle it was said, there are a lot of articles that provide a 5-line code solution on how to create it all over the place. No reason to be creating one on the fly every time you need it.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Tuesday, January 29, 2013 10:54 AM
Points: 3,837,
Visits: 3,821
|
|
|
|
|