|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 5:30 AM
Points: 861,
Visits: 1,436
|
|
Another great article! And it explains the reasons to use that technique going back to basics. Sometimes we know that we should do things one way or another because it's recommended everywhere but sometimes we don't exactly know "why" it's better. Articles that explain "why" are needed. Thank you.
Best regards,
Andre Guerreiro Neto
Database Analyst http://www.softplan.com.br MCITPx1/MCTSx2
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 6:46 PM
Points: 32,909,
Visits: 26,798
|
|
dwain.c (3/26/2012)
Outstanding article Jeff! Just what the doctor ordered for something I'm working on at this instant. I can't wait for the purists to berate you for using "pseudo" random numbers though.  And let me guess: DECLARE @Range INT ,@StartValue DATETIME ,@EndValue DATETIME
SELECT @StartValue = '2012-02-15', @EndValue = '2012-12-31'
SELECT @Range = DATEDIFF(day, @StartValue, @EndValue)
SELECT TOP 20 -- Random dates DATEADD(day, ABS(CHECKSUM(NEWID()) % @Range), @StartValue) As SomeRandomTime FROM sys.all_columns ac1 CROSS JOIN sys.all_columns ac2
SELECT @Range = DATEDIFF(second, @StartValue, @EndValue)
SELECT TOP 20 -- Random times (to the second) DATEADD(second, ABS(CHECKSUM(NEWID()) % @Range), @StartValue) As SomeRandomDate FROM sys.all_columns ac1 CROSS JOIN sys.all_columns ac2

I might be safe for the next 10 minutes or so. Although the "next" random value is certainly predictable, you'd have to know a fair bit about how NEWID() is generated to predict the next value 
You're just about spot on in your code. Just substitute @Range for the 20 in TOP 20 and Bob's your non-hardcoded Uncle. In Part 2, I'll explain how to easily include random times as a part of generating random dates. I'll also cover making period bins.
Thanks for the feedback, Dwain!
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 6:46 PM
Points: 32,909,
Visits: 26,798
|
|
codebyo (3/26/2012) Another great article! And it explains the reasons to use that technique going back to basics. Sometimes we know that we should do things one way or another because it's recommended everywhere but sometimes we don't exactly know "why" it's better. Articles that explain "why" are needed. Thank you.
You've hit the nail on the head, Andre. Random data generation is just like the Tally Table used to be. A lot of people were using it thanks to some posted code examples but they may not have known the "Why" of how it all worked. I wanted to make sure that people knew "Why" things worked the way they did so they can really think outside the box when the time comes.
Of course, the other reason I'm writing this is so that people who might not have otherwise been able to do so, can easily write some test data to see if that "works for 10 rows" code example they find on the internet is worth its salt. 
Thanks for the feedback and for "getting it".
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Today @ 2:33 PM
Points: 8,620,
Visits: 8,261
|
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 6:46 PM
Points: 32,909,
Visits: 26,798
|
|
Sean Lange (3/26/2012) Excellent article Jeff. Yet another home run!!! Your explanations are always so clear that even us lessers can understand. Keep them coming!!!
Heh... "lessers". I've seen your posts and I wouldn't associate the word "lesser" with someone like you. As you said, "Keep them coming!!!"
Thanks for the feedback, Sean.
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 2:17 AM
Points: 6,862,
Visits: 8,049
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 2:13 PM
Points: 43,
Visits: 306
|
|
Excellent post! Great examples, great code, and easy to follow! Nice job Jeff!
|
|
|
|
|
SSC-Insane
         
Group: General Forum Members
Last Login: Today @ 6:19 PM
Points: 21,624,
Visits: 27,464
|
|
Krtyknm (3/26/2012) Hi Jeff,
Nice Article, Keep going.
I have a question on sys tables, most of them using the Sys.tables for generating random numbers. Assume that developers don't have an access to System tables, then how can they get the random numbers.
Thanks, Karthik
In addition to what has already been said about using other tables, or creating a tally table, it is also possible to create a dynamic tally table using CTEs in SQL Server 2005 and newer. You can find numerous examples of these in the forums and articles on SSC.
 Lynn Pettis
For better assistance in answering your questions, click here For tips to get better help with Performance Problems, click here For Running Totals and its variations, click here or when working with partitioned tables For more about Tally Tables, click here For more about Cross Tabs and Pivots, click here and here Managing Transaction Logs
SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 9:31 AM
Points: 1,040,
Visits: 1,356
|
|
Jeff Moden (3/26/2012)
dwain.c (3/26/2012)
Outstanding article Jeff! Just what the doctor ordered for something I'm working on at this instant. I can't wait for the purists to berate you for using "pseudo" random numbers though.  I might be safe for the next 10 minutes or so. Although the "next" random value is certainly predictable, you'd have to know a fair bit about how NEWID() is generated to predict the next value 
For testing purposes (both scientific and software) pseudo-random numbers are preferable to truly random numbers*, because you want to see how the system responds to the entire range of possible inputs. A truly random number source cannot be trusted to give you a representative sample.
* This is, of course, assuming that the pseudo-random number generator produces uniformly-distributed data. More on that in a bit.
Edit: more on that: -- So the question becomes: does abs(checksum(newid())) produce a relatively uniform distribution of values? To test that, I created a dataset with the following code: (NOTE -- this generated 57 million rows on my test machine -- use with caution!)
select abs(checksum(newid())) as RandValue into RandIDTesting from sys.all_columns ac1 cross join sys.all_columns ac2
I then wrote the following code to see how the data is distributed:
declare @RangeMin int = 0 declare @RangeMax int = 2147483647 declare @RangeInc int = 65536 declare @RangeCount int = @RangeMax/@RangeInc select @RangeMin, @RangeMax, @RangeInc, @RangeCount;
with Ranges as ( select top (@RangeCount+1) @RangeMin + @RangeInc * (row_number() over (order by (select null))-1) as RangeStart, @RangeMin + @RangeInc * (row_number() over (order by (select null)))-1 as RangeEnd from sys.all_columns ac1 cross join sys.all_columns ac2 ) select RangeStart, RangeEnd, (select count(*) from RandIDTesting where RandValue between RangeStart and RangeEnd) as RangeSize from Ranges group by RangeStart, RangeEnd order by RangeStart
This produced a list of ranges and how many of our pseudo-random numbers fell into that range. In my testing, all of the ranges had between roughly 1500 to roughly 1700 numbers in it. So in this case, this method did produce a relatively uniform sample set. This is not conclusive, but you can methods similar to the above to test for yourself.
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 7:57 PM
Points: 6,998,
Visits: 13,949
|
|
sknox (3/26/2012) For testing purposes (both scientific and software) pseudo-random numbers are preferable to truly random numbers*, because you want to see how the system responds to the entire range of possible inputs. A truly random number source cannot be trusted to give you a representative sample.
* This is, of course, assuming that the pseudo-random number generator produces uniformly-distributed data. More on that in a bit.
That's a good point to bring up. A random distribution will create a uniform distribution across a range of data, but cannot on its own replicate any non-uniform data patterns. So if you're looking to find out if there's a normal distribution in your data (or any number of other patterns across the set), using random data may not be a good option.
This would be one of those big caveats in the "why would you need random data". The random set will allow you to test for behavior of a varity of inputs at the detail level, but won't help with test the set as a whole.
---------------------------------------------------------------------------------- Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
|
|
|
|