Natural vs surrogate keys on support tables

Posted by Bugeo on Stack Overflow See other posts from Stack Overflow or by Bugeo
Published on 2012-10-05T14:30:05Z Indexed on 2012/10/05 15:37 UTC
Read the original article Hit count: 294

I have read many articles about the battle between natural versus surrogate primary keys. I agree in the use of surrogate keys to identify records of tables whose contents are created by the user.

But in the case of supporting tables what should I use?

For example, in a hypothetical table "orderStates".

If you use a natural key would have the following data:

TABLE ORDERSTATES
{ID: "NEW", NAME: "New"}
{ID: "MANAGEMENT" NAME: "Management"}
{ID: "SHIPPED" NAME: "Shipped"}

If I use a surrogate key would have the following data:

TABLE ORDERSTATES
{ID: 1 CODE: "NEW", NAME: "New"}
{ID: 2 CODE: "MANAGEMENT" NAME: "Management"}
{ID: 3 CODE: "SHIPPED" NAME: "Shipped"}

Now let's take an example: a user enters a new order.

In the case in which use natural keys, in the code I can write this:

newOrder.StateOrderId = "NEW";

With the surrogate keys instead every time I have an additional step.

stateOrderId_NEW = .... I retrieve the id corresponding to the recod code "NEW"

newOrder.StateOrderId = stateOrderId_NEW;

The same will happen every time I have to move the order in a new status.

So, in this case, what are the reason to chose one key type vs the other one?

© Stack Overflow or respective owner

Related posts about database-design

Related posts about primary-key