Logical Data Modeling - (Surrogate | Substitute | Synthetic | Generated ) Primary key


A surrogate key is a substitute primary key for when:

  • the data entity are created in distributed way
  • you don't have access to a central entity such as database to create a simple sequence
  • you don't have a natural one (entity not found for instance)
  • the key is too long for the database (example: url for a web page)

Since the value has no meaning, there is unlikely to be any demand for a change making them true primary key.

Surrogate means to choose in place of another

It's a primary key that holds a generated value.

A surrogate key exists almost always next to a business key.


  • An ID column populated via a database sequence is known as a surrogate key. - It works only when data is being inserted into only one database (not many databases at the same time)
  • A ObjectId - A random hash-based generated value for Json object
    • of a long natural key (such as an URL)
    • of all values of the record
SELECT * FROM tbl_name
  WHERE surrogate_pk=MD5(urlValue)
  AND url=urlValue;


No key

If there is no logical unique and non-null column or set of columns


Numeric values also produce shorter values of predictable length. Storing numeric codes in place of string is more space-efficient.

Dimensional Modeling

The use of SKs in dimensional modeling is not only simplicity of star design or performance.

You often need to populate dimensions with extra records not found in the source table, such as:

  • or “NOT APPLIES” records.

If you don't use SKs, What PK value would you use for this extra records?

How can you be sure that the values you choose won't collide with future records from the source table?

Also, taking your dimensional schemas away from possible source key changes is a good idea. Of course creating and maintaining SKs adds complexity and is extra work for ETL processes.


Sortable by Time

If the id are sortable by time. a list entity could be sorted without fetching extra information.



IDs should ideally be short enough.

Database system are generally limited at 64 bits to store integer


collision probability should be acceptable


Surrogate key may be implemented via:

Database Sequence

A sequence (auto-incrementing number) in a database is suitable in a centralized architecture. If the id can be generated decentralized, you need to add more information to make them unique (ie the time and node name for instance as instagram does)

Server-side generated identifiers are pretty much guaranteed to be unique.


Via the standard guid outside a database (distributed)


Bootstrap implements it as a completly random number 1)

const MAX_UID = 1000000
const getUID = prefix => {
  do {
    prefix += Math.floor(Math.random() * MAX_UID)
  } while (document.getElementById(prefix))

  return prefix

Generated / Object Id

Generated outside a database:

In datawarehouse, they may implements a not/so real surrogate key as a hash of the value of all columns.


device fingerprinting is also a generated way to identify an individual.


Nanoid is a random ID string comparable to UUID v4 (random-based)

  • URL friendly
  • 21 characters (vs 36 with UUID because of a bigger alphabet).
  • Polyglot: 14 languages

If the number of id generated is small, you can reduce the size: Collision probability by size (See also Collisions of Hash or Identifier Generation)

const { nanoid } = require('nanoid');
nanoid(15); //=> "YrxC0J7fBQobaL-"


Universally Unique Lexicographically Sortable Identifier


Documentation / Reference

Powered by ComboStrap