ListMistress

I'm pretty sure that's just snark.... Lines like 'Your DBA is likely the best looking and smartest person in your IT department.' are you clue.

Seems to me some of those solutions are worse (more expensive) than just fixing poorly performing queries.

I agree, neither phone numbers nor social insurance numbers are unique.

But the issue is with storing them in numeric datatypes. They aren't guaranteed to be unique forever (and indeed, are alphanumeric in many jurisdictions) and the leading zero problem is a killer when you go to reconstitute them, both for performance and for logic reasons. Same goes for US ZipCodes.

This is why I have to have a very strong technical reason to make a non-math column numeric, especially with externally set data (like SSNs, SINs, Account codes, etc.) The people who set them could just start adding letters or symbols...and this isn't rare.

GUIDs are HUGE and have a significant impact on performance. Go read Kimberly Tripp's blog post referenced in the article. She does the math for you.

In almost all the cases that I see GUIDs, they were totally unnecessary for the design. Even the developer who designed them could not give a reason why they needed to be GUIDs. A row unique across the entire universe? Really?

I'm not saying there are no cases...just that in most cases they negatively impact performance with little business or logic gain for that price. All design decisions come down to cost, benefit and risk.