Natural Is Not Always Best

by Hieu H
One of the hottest debates with no real winner in the database world is the argument of which are better, surrogate or natural keys. Natural keys are keys that are existing data, such as a customer’s social security number. Surrogate keys introduce a new column that has no business meaning whatsoever. Mullins’ article gives the views of both the proponents and opponents of surrogate keys. Those who sided with surrogate keys argues that they are easier to manage and are more uniform. Usually, surrogate keys are integers, making them easier to deal with especially in multi-database environments. Those who do not like surrogate keys argue that surrogate keys are useless and have no real world meaning. They argue that an extra row of data may cause performance issues because you need to include an extra row in your SQL queries. The debates goes on and on with no clear winner. The final answer according to Mullins is “it depends.”

This is a great article on so many levels. We’ve learned in what primary keys are and how to choose them. This article helps us to think about the business and technological context of our choices. To realize that something as simple as choosing a primary key could affect such things as database security, it makes us wonder how important some of our other seemingly small decisions are.

I was taught from day one to use surrogate keys. In fact, most database tutorials that you read online will use surrogate keys. One thing that I like about surrogate keys is that they are assigned, therefore, it can automatically be done. A popular way of doing so is to have the column auto-increment. However, after reading this article, I may have to think more about which type of keys to use.

Mullins, C. (September 2012). Surrogate Keys or Natural Keys. Database Trends and Applications, 26(3), 37.

One thought on “Natural Is Not Always Best

  • November 11, 2012 at 11:12 pm

    I find it interesting that people can come up with a key that has no business meaning and be able to use it practically. I guess that it really would depend on what ind of database it was, how large, how many administrators it has, and what the business needs. Right now in my database life, I feel that the less amount of columns and rows I have to deal with, the better. But who knows, the better I get, the more appealing surrogate keys will become.

Comments are closed.