June 5, 2007 at 9:31 am
I'm looking for an easy way to have a unique random number column on a table - to be generated when inserting multiple records, rather than by single inserts - e.g.
USE NORTHWIND
CREATE TABLE #TestRnd (
pKey INT IDENTITY(1,1),
MyData Varchar(50),
Random1 FLOAT default RAND(),
Ramdom2 UniqueIdentifier default NEWID() )
INSERT INTO #TestRnd
(MyData)
SELECT ContactName FROM Customers
I get the same random number for every row in column Random1. Random2 is unique - and looks random enough, but I want a numeric field, and pKey may be unique and numeric but its not random!
June 5, 2007 at 9:57 am
My first and only question is why do you want to do that for?
June 5, 2007 at 1:40 pm
If the need is for uniqueness and not keys you may want to consider timestamp datatype
-
June 6, 2007 at 2:02 am
June 6, 2007 at 4:38 am
Hi,
are you using the Ramdom2 column for replication purposes, or do you just want a column with a random number in it.
You can convert NEWID() to a positive integer using the cumbersome conversion
ABS(CAST(CAST(NEWID() AS BINARY(16)) AS BIGINT))
But you will not be able to store an integer value in a UniqueIdentifier column, you would have to drop the UniqueIdentifier status or create a view based on your table which displayed the NEWID() value as a number.
David
If it ain't broke, don't fix it...
June 6, 2007 at 7:29 am
First Ninja's point: I'm porting a "shadow IT" application written in Access and VB6 - Its a production line sequencing program to keep a balanced workload on the assembly track. Quite often several orders get the same score (i.e take the same amout of work to build), and the random number is to distinguish between them.
Jason: currently the random number is used as a multiplier, so has to be numeric. I could change the logic, but the existing application gives the right results, so I'm reluctant.
And Adrian's point: The pkey is no good as items are added in batches meaning you might get all 'red' orders then all 'blue' orders if pkey is used. This is bad as if the 'red' components are running out, you want time to notice and resupply, so the mix has to be as random as possible. If 'red' runs out completely and a 'red' order appears, the assembly line stops causing major grief to all.
Thanks to David for the suggestion to use CAST.
Tom
June 6, 2007 at 9:49 am
"Jason: currently the random number is used as a multiplier, so has to be numeric. I could change the logic, but the existing application gives the right results, so I'm reluctant."
The timestamp datatype can be converted to numeric (i.e: Select cast([Timestamp column] as INT) from [Your Table])
However, David's suggestion applies to your situation much more effectively because the timestamp column value will change with each insert, update, while the newid value will remain constant once inserted.
When you use the UniqueIdentifier, to avoid needing to remove the UI status or create other views you can set the default value of your unique column (defined as BIGINT) to the cast provided by David. Here is a quick example.
CREATE Table tblTest (iId INT IDENTITY(1,1) PRIMARY KEY,vcValue VARCHAR(255),biUniuque BIGINT DEFAULT ABS(CAST(CAST(NEWID() AS BINARY(16)) AS BIGINT)))
-
June 6, 2007 at 10:03 pm
If you want an integer, you can use this as the default for your column:
abs(convert(int,convert(varbinary(16),newid())))
June 7, 2007 at 5:16 am
Perhaps I'm doing something wrong, Joe... the T-SQL example you posted (repeated below), generates the sequence of numbers that follows that and repeats... not random at all...
CREATE TABLE Generator31 (keyval INTEGER NOT NULL);
INSERT INTO Generator31 VALUES (1); -- any start value
UPDATE Generator31
SET keyval =
keyval/2 + ((keyval % 2) + (keyval/8 % 2) % 2)* 8
SELECT * FROM Generator31;
8
12
14
15
23
19
17
16
8
12
14
15
23
19
17
16...
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply