Surrogate keys (Was: enums)

From: Leandro Guimarães Faria Corcete DUTRA <leandro(at)dutra(dot)fastmail(dot)fm>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Surrogate keys (Was: enums)
Date: 2006-01-13 12:42:55
Message-ID: loom.20060113T133918-638@post.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rod Taylor <pg <at> rbt.ca> writes:

> The basic idea is that most of us break out schemas by creating fake
> primary keys for the purpose of obtaining performance because using the
> proper primary key (single or multiple columns) is often very slow.

This is one thing I simply can't understand.

If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs and
INSERTs, two indexes to be updated, and probably a SEQUENCE too.

If you don't, you have just thrown away centralised, optimised integrity
checking, and will probably have to remember to do a slower SELECT before
updating.

Certainly decoupling presentation from storage would be nice, but even before
that generalised use of surrogate keys seems to me a knee-jerk reaction.

In response to

  • Re: enums at 2005-10-28 18:57:03 from Rod Taylor

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2006-01-13 13:38:07 PostgreSQL win32 & NT4
Previous Message St Valentine 2006-01-13 10:52:57 C++ -> C : Module for converting the WHERE clause to the canonical form with PostgreSQL