I'm working with a legacy database that stores GUID values as a varchar(36) data type:
CREATE TABLE T_Rows (
RowID VARCHAR(36) NOT NULL PRIMARY KEY,
RowValue INT NOT NULL
)
INSERT T_Rows (RowID, RowValue) VALUES (NEWID(), 1)
I would assume that storing a GUID as a uniqueidentifier would be preferable since it's only 16 bytes in size as opposed to 36.
Are there any advantages to storing a GUID as a varchar?
Perhaps only the fact that you can 'read' them from a SELECT statement (although I don't think that's particularly useful as you can use a function in a select to make Uniqueidentifiers displayable).
If the table is large, saving 20 bytes per row is considerable.
I would go with uniqueidentifier for many reasons such as,
it will take less space; it's unique so it can not be duplicated. It's much better for comparisons and specially performance related issues as well as easy to get unique default value etc.
I would use uniqueidentifier unless I need to use varchar for very specific reason.
If your database is Oracle then the performance of indexes for raw data in older version of Oracle (9) was much, much poorer than indexing a varchar(36) field. Luckily this has changed in Oracle 10 and 11.
I believe UNIQUEIDENTIFIER was added in SQL Server 2000, so it's possible this application was originally written for SQL Server 7, which didn't support it. But that's just a guess, of course...
Absolutely not, as I'm sure you know legacy databases often suffer from design flaws :P Because GUID is 16 bytes, it might as well take up 16bytes in the database. You'll gain that 20 bytes per entry
来源：https://stackoverflow.com/questions/3527044/guid-varchar36-versus-uniqueidentifier