views:

46

answers:

1

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?

+2  A: 

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.

Ed Harper
In the future, merging of data could become a requirement. Perhaps at that time it can be solved with an extra "server id" as described in the article link.
Jappie