问题
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?
回答1:
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.
回答2:
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.
回答3:
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.
回答4:
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...
回答5:
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