CELKO (10/2/2014)
Natural Keys have a tendency to take inserts all over their spectrum. This fragments indexes very quickly, and unnecessarily.
No, not usually. Think about manufacturing processes. VIN, ISBN, et al all have a sequence inside them. Their prefix is constant and tells us about something important for processing. Look at your credit card numbers. An ISO/IEC 7812 card number is most commonly 16 digits in length:
a six-digit Issuer Identification Number (IIN) (previously called the "Bank Identification Number" (BIN)) the first digit of which is the Major Industry Identifier (MII),
a variable length (up to 12 digits) individual account identifier,
a single check digit calculated using the Luhn algorithm.
The ISAN is the only random identifier standard I can think of.
If I am storing the VIN numbers of cars I service, every one of them will be entered in an essentially random portion of the PK, and not at the end, where they belong. Same with ISBNs for books I sell. I don't control those, I simply have them entered. What if I am entering bank codes so I can direct deposit for my employees? Should I use that natural key?
The answer is, of course, no. In nearly all cases, a natural key is inferior to a surrogate key for maintaining order & performance in a DB, because in nearly ALL cases the people using them do NOT control their issuance. The claim that the OP should "read a book" or "Newbies prefer to do it wrong by using auto-increments" - when the real answers are RIGHT HERE - is insulting, and unneeded on a forum dedicated to SQL Server. It's a legitimate question, BIGINT vs. GUID, and rightfully belongs here. Feel free to respond, but leave the insults behind, especially when you are so clearly wrong.
-----------------------------
I enjoy queries!