Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
GUID as PK
Message
From
07/12/2005 08:50:37
Mike Yearwood
Toronto, Ontario, Canada
 
General information
Forum:
Microsoft SQL Server
Category:
Other
Title:
Miscellaneous
Thread ID:
01075523
Message ID:
01075682
Views:
17
Hi Einar

http://www.sql-server-performance.com/zn_guid_performance.asp

http://www.informit.com/articles/article.asp?p=25862&rl=1

Interestingly enough, the second article despite proposing something faster than the GUID fails to examine the advantages of having many clients generate their own PK. I always think about the server in terms of a subway. The more people who take their time getting on and off the subway before it comes to my station, the longer I have to wait. The server could be spared the task of generating the key.

>Gary,
>Reading between the lines I assume that you are a fan of int (or bigint if needed) for PK.
>I realize that there is a "big" space penalty for choosing a GUID (although it is only 8 bytes more than a bigint), but is disk space really a concern anymore? Disk space is cheep and almost unlimited. Now speed that is always an issue. I realize that a GUID PK will take longer than an int to index and join and all that, but I have not found any documentation that can give me an statistics about this. So I don't know if this is a major or minor issue.
>
>I agree that it is really application dependent, and maybe it was silly of me to ask such a general question (on 2nd thought not it wasn't silly). I am not sure if I will draw any conclution from the answers I see here, but I still find it interesting.
>
>Einar
>
>>>Who uses GUIDs for PK? Why?
>>
>>Unless you want a PK that is unique across space and time, then GUID is not really necessary. Also, this takes a *lot* of space and a higher indexing overhead.
>>
>>>Who prefer bigint (or int) for their PK? Why?
>>
>>This is solely down to your knowledge of the application and whether you think the range of numbers offered by an Int will always be sufficient for your PK needs. Generally, I think most "normal" systems (if there is such a thing) would find Int to be perfectly acceptable for PKs. If you wanted to be doubly sure, go ahead and use Bigint as it will do no harm but, if you don't really need the number range offered by Bigint, then you are just using/wasting space in the database.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform