dbishop (9/22/2009)
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.
Curious, what happens if you find yourself in a shop where you aren't allowed to create a static tally table, what are you going to do? This is a problem we see quite frequently on the forums, as Luke mentions above, when a tally table solution is suggested.
In addition, this article may make a little more sense if you take to the time to read the article I also referenced that was published in the May 2009 edition of SQL Server Magazine. This article is in response to that article, demonstrating that there is a better way to generate a dynamic tally table.