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

Re: pervasiveness of surrogate (also called synthetic) keys

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pervasiveness of surrogate (also called synthetic) keys
Date: 2011-05-03 23:36:00
Message-ID: 4DC09160.60800@gmail.com (view raw or flat)
Thread:
Lists: pgsql-general

On 05/03/2011 03:08 PM, Jeff Davis wrote:
> On Tue, 2011-05-03 at 13:35 -0600, Rob Sargent wrote:
>> Sorry, but I'm confused, but that's common.  Isn't a "natural key" to be
>> compose solely from the attributes of the entity?  As in a subset of the
>> columns of the table in a third-normalish world. Isn't tacking on
>> another column with a concocted id joining the "pervassiveness"?
>
> Not in my opinion. Before cars existed, there was no driver's license
> number. The DMV (as it's called in California, anyway) created it, and
> it's now a key that they can trust to be unique. It's also an attribute
> of the entity now, because it's printed on the cards you hand to people.
>
> The thing that I think is a mistake is to use generated IDs like an
> internal implementation detail (i.e. hide them like pointers); then at
> the same time mix them into the data model.
>
> Regards,
> 	Jeff Davis
>
>
>
Well yes it does all depend on how you model things after all. I think a 
drivers license is and attribute of driver not person. So before cars, 
one still had a hard time coming up with a natural key on person.  Of 
course California's DMV only cares about Californian licenced drivers, 
so they get to generate and assign license number as an arbitary key for 
drivers 'cause under that we're back to person.

In response to

pgsql-general by date

Next:From: Greg SmithDate: 2011-05-04 02:03:04
Subject: Re: pervasiveness of surrogate (also called synthetic) keys
Previous:From: dabichoDate: 2011-05-03 23:15:41
Subject: Re: Question on Wal time lines

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