Recent PostsRecent Posts Popular TopicsPopular Topics
 Home Search Members Calendar Who's On

 Generating Test Data: Part 1 - Generating Random Integers and Floats Rate Topic Display Mode Topic Options
Author
 Message
 Posted Monday, March 26, 2012 6:35 AM
 SSC Eights! Group: General Forum Members Last Login: Thursday, December 05, 2013 4:30 AM Points: 880, Visits: 1,462
 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 NetoDatabase Analysthttp://www.softplan.com.brMCITPx1/MCTSx2
Post #1272597
 Posted Monday, March 26, 2012 6:36 AM
 SSC-Dedicated Group: General Forum Members Last Login: Yesterday @ 6:24 PM Points: 34,557, Visits: 28,738
 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 DATETIMESELECT @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 ac2SELECT @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." "Change is inevitable. Change for the better is not." -- 04 August 2013(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013Helpful Links:How to post code problemsHow to post performance problems
Post #1272598
 Posted Monday, March 26, 2012 6:46 AM
 SSC-Dedicated Group: General Forum Members Last Login: Yesterday @ 6:24 PM Points: 34,557, Visits: 28,738
 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." "Change is inevitable. Change for the better is not." -- 04 August 2013(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013Helpful Links:How to post code problemsHow to post performance problems
Post #1272613
 Posted Monday, March 26, 2012 7:33 AM
 SSChampion Group: General Forum Members Last Login: Wednesday, December 04, 2013 2:23 PM Points: 10,854, Visits: 10,012
 Excellent article Jeff. Yet another home run!!! Your explanations are always so clear that even us lessers can understand. Keep them coming!!! _______________________________________________________________Need help? Help us help you. Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.Need to split a string? Try Jeff Moden's splitter.Cross Tabs and Pivots, Part 1 – Converting Rows to Columns Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs Understanding and Using APPLY (Part 1)Understanding and Using APPLY (Part 2)
Post #1272654
 Posted Monday, March 26, 2012 7:48 AM
 SSC-Dedicated Group: General Forum Members Last Login: Yesterday @ 6:24 PM Points: 34,557, Visits: 28,738
 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." "Change is inevitable. Change for the better is not." -- 04 August 2013(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013Helpful Links:How to post code problemsHow to post performance problems
Post #1272666
 Posted Monday, March 26, 2012 7:49 AM
 SSCertifiable Group: General Forum Members Last Login: Friday, December 06, 2013 7:25 AM Points: 6,982, Visits: 8,360
 Great extrapolation of the KISS principle, Jeff.Need it to be sead ... I LOVE IT JohanDon't drive faster than your guardian angel can fly ...but keeping both feet on the ground won't get you anywhere - How to post Performance Problems- How to post data/code to get the best help- How to prevent a sore throat after hours of presenting ppt ?"press F1 for solution", "press shift+F1 for urgent solution" Need a bit of Powershell? How about thisWho am I ? Sometimes this is me but most of the time this is me
Post #1272668
 Posted Monday, March 26, 2012 9:04 AM
 SSC Rookie Group: General Forum Members Last Login: Thursday, November 21, 2013 12:18 PM Points: 44, Visits: 319
 Excellent post! Great examples, great code, and easy to follow! Nice job Jeff!
Post #1272750
 Posted Monday, March 26, 2012 9:14 AM
 SSC-Insane Group: General Forum Members Last Login: Yesterday @ 8:12 PM Points: 22,092, Visits: 29,013
 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,KarthikIn 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.
Post #1272762
 Posted Monday, March 26, 2012 9:15 AM
 Ten Centuries Group: General Forum Members Last Login: Yesterday @ 5:05 PM Points: 1,177, Visits: 1,532
 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 RandValueinto RandIDTestingfrom sys.all_columns ac1cross join sys.all_columns ac2 `I then wrote the following code to see how the data is distributed:`declare @RangeMin int = 0declare @RangeMax int = 2147483647declare @RangeInc int = 65536declare @RangeCount int = @RangeMax/@RangeIncselect @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 RangeEndfrom sys.all_columns ac1cross join sys.all_columns ac2 )select RangeStart, RangeEnd, (select count(*) from RandIDTesting where RandValue between RangeStart and RangeEnd) as RangeSizefrom Rangesgroup by RangeStart, RangeEndorder 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.
Post #1272765
 Posted Monday, March 26, 2012 1:51 PM
 SSCertifiable Group: General Forum Members Last Login: Yesterday @ 10:28 PM Points: 7,020, Visits: 14,248
 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?
Post #1272958

 Permissions