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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-general by date

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