Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
For primary keys on a large SQL Server 2008 data table, I have the choice of using guids or a string of about the same size.
Performance-wise, how does a guid (16 bytes) compare to a string of about 16 chars, when doing joins, selects, etc. Is SQL better at handling guids because internally they are represented as a number?
The short answer to your question is, ideally, to use neither.
If you can use an int/bigint key (as I suggested in my answer to your related question), you should.
Unless you need the functionality to non-destructively merge copies of this dataset stored on more than one SQL Server instance, using a GUID primary key adds a considerable overhead in index maintenance. This article has a reasonable discussion of the issue.
A string PK should have less overhead if the sequence you generate is consistently ordered – i.e. new values are always added at the “end” of the table.