Skip site navigation (1) Skip section navigation (2)

Re: pervasiveness of surrogate (also called synthetic) keys

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: pervasiveness of surrogate (also called synthetic) keys
Date: 2011-05-02 00:59:52
Message-ID: BANLkTikHuQqyEvoFX7omb4TGBPkMPO8+vw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Apr 28, 2011 at 3:07 PM, Karsten Hilbert
<Karsten(dot)Hilbert(at)gmx(dot)net> wrote:

> I must agree with a recent poster
> that what appears to identify as a natural key often really
> isn't or else becomes not so later on. It's vastly easier to
> then deal with that by re-defining constraints without
> having to touch primary keys.

I have run into this.  Often what happens is that the data model
directly affects the assumptions coders make.  In a system I worked
on, the username was unique / primary key.  Code was written that
assumed username would always be unique across the app.  Then the app
was deployed to multiple non-associated groups, where user names from
two different organizations might be the same and they couldn't be
changed.  Talk about some ugly code changes needed to be made to fix
all the bugs.  ugh.  An initial assumption that a serial value would
be unique, but usernames might not be would have resulted in a much
cleaner design for that system.  Or even that the PK was org||username
or something.

In response to

pgsql-general by date

Next:From: gvimDate: 2011-05-02 01:37:57
Subject: "IS LATER THAN" filter for date column
Previous:From: Karsten HilbertDate: 2011-05-01 22:12:59
Subject: Re: pervasiveness of surrogate (also called synthetic) keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group