RAND function is really pseudo-random in the sense that it generates the same sequence of numbers if you start with the same seed. If you want truly random, you might consider using newid() function. For example ABS(CHECKSUM(NEWID())) % 10000
Slightly different take on this for 1 or a million values...
--===== Declare the variable and populate it in the same line of code.
DECLARE @RandomNumber CHAR(4) = RIGHT(ABS(CHECKSUM(NEWID())%10000)+10000,4)
;
--===== Pretty easy to make a million of them, as well.
SELECT TOP 1000000
RandomNumber = RIGHT(ABS(CHECKSUM(NEWID())%10000)+10000,4)
FROM sys.all_columns ac1
CROSS JOIN sys.all_columns ac2
;
What is it that you're trying to figure out? There are a couple of solutions that do things as requested. They also work for entire columns where just RAND() without the proper seed won't.
Performance Tuning
when actual Data is only 1000 rows
is very tough
In Performance Tuning
My experience has been
It takes a different mind set
Stuff like Lots of Temp tables etc etc
Logical Reads .. Reducing
And in companies I do not have "permissions"
I agree that performance tuning when the actual data is only 1000 rows is tough. That's why I use the techniques in the two articles I post to usually test for 1 Million rows.
Absolutely correct. There are "Devils in the Data" and that's why I like QA people a whole lot. They come up with things that I can only imagine.
And that's why I wrote the two articles I provided links to. If you put a couple of things together using those techniques, you can test a shedload and it's fairly easy to come up with all sorts of scenarios.
Heh... you might say that. I'm the guy that created the term "RBAR" and popularized the name "Tally Table" instead of calling a table of sequential numbers a "Numbers Table".
A pleasure to "meet" you, as well. And, to be sure, we all started out as novices. I had SQL Server thrust upon me back in '96. I was truly an "accidental DBA" and, although it was "fun", it was trying (heh... still is, sometimes). There's so much to learn about SQL Server. While I'm pretty darned good at T-SQL and other things like indexes and the like, I'm still a rank novice in a lot of areas.
That's all a part of the reason why I taught myself how to build shedloads of test data. I found a website way back then called "Belution.com" and was a fairly active member. A lot of what I saw, when it came to issues of performance, was based on hear-say, opinion, and "Best Practices" that actually turned out to be not so good and so decided to "let the code do the talking" for me. Unfortunately, Belution.com went offline more than a decade ago.
With sites like this one (SQLTeam.com) and the good people (there are some serious heavy hitters on this and other forums), it's pretty easy to find new and sometimes better ways even for an old dog like me.
Thank you for the very kind words but... we're all in this together... everyone is "worthy". Not sure about being a "legend" either. Like Brent Ozar says, I've just made more mistakes than a lot of people have and can sometimes help others avoid them.