The Case for the Surrogate Key

By Bill Graziano on 9 August 2002 | Tags: Table Design


There is a simple, inexpensive, uniform element of database design that you are likely avoiding in favor of a complex, costly, and inconsistent one. This element is the surrogate or substitute primary key. It seems that designers avoid these independent keys like the plague. Instead, all but the most basic business entities are given keys made up of some series of attributes, borrowed keys, and sequence numbers . It was only after experiencing many problems at the hand of intelligent keys that I, too, became a believer in the flexibility and stability afforded by the substitute key. This is a pretty good article on when you can use a surrogate key. And I thought we didn't get enough discussion on this from Rob's article.

Link: The Case for the Surrogate Key


Related Articles

Implementing Table Interfaces (19 May 2008)

Implementing Table Inheritance in SQL Server (20 February 2008)

Custom Auto-Generated Sequences with SQL Server (24 April 2007)

Using TABLE Variables (7 June 2002)

More Trees & Hierarchies in SQL (1 May 2002)

Default Constraint Names (24 January 2001)

Temporary Tables (17 January 2001)

Denormalize for Performance (10 January 2001)

Other Recent Forum Posts

Checkmark for guaranteed SR = WR (104m)

How to connect to git in SQL Server 2016/2017 without using any third party tool (112m)

Sql restart (7h)

Excel column wise data save in rows (1d)

Date timzone conversion (1d)

Object cannot be cast from DBNULL to other types coming randomly in SSIS Package-Migrated from VS 2008 to 2015,SQL 2008R2 to SQL2016 on 1st run only (2d)

Error in sp procedure- Msg 50000, Level 16, State 1, Procedure spCheckDBInfo, Line 193 [Batch Start Line 0 (2d)

Two records into a single record? (2d)

- Advertisement -