Database Keys - Natural versus Surrogate

I always like to add my own 2 cents worth to humourous database normalization discussions that I read on the net. Recently I read an old article on SqlTeam.com about prudently choosing when to use candidate versus surrogate database keys. Of course, I agree with the author about being prudent and creating a surrogate key. But his example is a very poor choice.

He presents an example of why a surrogate key is not necessary for an employees table, since there is already a way to uniquely identify employees, which is through the use of the BossLan database column. The BossLan database column represents the company's Novell LAN user names. This is one of the places where his article is completely misguided. Although his intent and point are good, it is crucial that a database model is designed with a level of agility to it, so that it can withstand changes to its environment. What happens when the company switches from Novell to Microsoft or some other platform?

I found some more humour linked to at r937.com.

Anyways, I noticed this while I have been modeling for a new application that I am developing. So, before you feel you've struck modeling gold and have found an insulted, magical candidate key within a database table, think hard about the long term changes that may occur in the environment that surrounds the columns of that key!

So, before you go ahead and use your Active Directory user names or Novell LAN user names as your unique key for your employee tables, consider how insular your decision is to long term company changes. And if you're not sure what those company changes may be, consider surrogate keys!