by Mike.Sheen » Wed Dec 10, 2008 7:12 pm
Ok, today I've laid the groundwork for this, and UniqueIdentifier datatypes are in.
So, most tables will look something like this :
CREATE TABLE IN_Main
(
RecID UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID(),
... // some more fields
LastSavedDateTime DATETIME NOT NULL,
RowHash TIMESTAMP NOT NULL
)
We are making use of the OUTPUT clause in the insert syntax for SQL 2005/2008 to read back the generated ID on insert.. so the actual SQL we issue looks something like this :
INSERT INTO IN_Main(PartNo, Description, ..., LastSavedDateTime)
OUTPUT Inserted.RecID
VALUES(@PartNo, @Description, ... GetDate())
What this means, is - as James quite rightly pointed out - is reduced row size and increased performance.
Anyone worried about how one writes queries in TSQL for UniqueIdentifier column literals should be able to rest at ease : you can provide literals easy enough..
eg :
SELECT * FROM IN_Main WHERE RecID = '6F9619FF-8B86-D011-B42D-00C04FC964FF'
works fine, as does :
SELECT * FROM IN_Main WHERE RecID = 0x6F9619FF8B86D011B42D00C04FC964FF
The above two queries are both valid, and would return the same row - just the latter uses the binary literal and the former uses a string literal. At the end of the day, the data stored is a 16 byte binary value - MS was just kind enough to allow queries to provide either a string or binary literal.
Mike Sheen
Chief Software Engineer
Jiwa Financials
If I do answer your question to your satisfaction, please mark it as the post solving the topic so others with the same issue can readily identify the solution