Re: pervasiveness of surrogate (also called synthetic) keys

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pervasiveness of surrogate (also called synthetic) keys
Date: 2011-05-03 06:11:15
Message-ID: 4DBF9C83.2060904@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

John R Pierce wrote:
> otoh, there's plenty of places where natural keys are optimal. my
> company makes widgets, and we make damn sure our serial #s and part
> numbers are unique, and we use them as PK's for the various tables.

Sure; what I was commenting on is that you normally can't ever trust
external sources for identifiers. If you want to come up with your own,
internally unique keys for things, great. But one of the goals of using
a natural key is often to avoid the overhead of storing both that ID and
some made up internal number, too. And whether the number is made up by
the computer (the classic SERIAL or similar surrogate key), or you make
one up yourself, it's still another chunk of data that gets stored for
every item. It's just one that means something more useful in your
case. Probably going to take up more space in the process and possibly
be slower though--part number strings can easily end up longer than
SERIAL-like integers.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Browse pgsql-general by date

  From Date Subject
Next Message tushar nehete 2011-05-03 06:15:27 Bidirectional replication
Previous Message Tom Lane 2011-05-03 05:39:46 Re: Seg Fault in backend after beginning to use xpath (PG 9.0, FreeBSD 8.1)