...
- SQL engines often default to using the primary key as the “Clustered Index”, which means it physically stores the records in that order. If you’re assigning random values, then the server will be reworking the file regularly to get those records in order. Therefore, you must explicitly tell your database to use a different key as the clustered key. (By the way, I've read that choosing the best key for clustering is one of the best techniques for efficient queries, and supposedly the primary key isn't usually the best key, so this is something you should ponder regardless.)
- According to Bruce Johnson at Capesoft, the speed impact is small, but I’ve spoken with administrators working on large databases with many new transactions each day, and they were uneasy about using this approach.
- Long strings take up more space than compact integers, so your database will be bigger (and consequently slightly slower).When debugging, working with random strings isn’t as easy as sequential numbers.
- On SQL Server the primary clustered key is included for all other index entries, so if you do use a GUID with a clustered primary key (the default) then you're potentially using a lot more data storage. .
- When debugging, working with random strings isn’t as easy as sequential numbers.
Do I Really Have to Change?
...