pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Stark <gsstark@mit.edu>
To: David Clarke <pigwin32@gmail.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Table design question
Date: 01 Jun 2006 11:40:59 -0400
Message-ID: <87slmohoj8.fsf@stark.xeocode.com> (raw)
In-Reply-To: <12b7ac1e0606010405u6e062f71mf4adbaeb6c46df5f@mail.gmail.com>
References: <12b7ac1e0606010405u6e062f71mf4adbaeb6c46df5f@mail.gmail.com>


"David Clarke" <pigwin32@gmail.com> writes:

> is it really that big an issue these days to have a 100 character primary
> key? Are there postgres-specific implications for either approach?

It's exactly the same size issue as ever. A 20% increase in space usage is a
20% performance hit in certain types of queries regardless of how fast or
cheap your hardware has become.

This is an issue where reasonable people differ quite vociferously so you may
get contradictory responses. But really it depends heavily on the exact
circumstances and requires a judgement call based on experience. Any time
someone tries to sum it up with a blanket rule it's going to be wrong some of
the time.

But that said I also tend to tilt towards creating serial ids. Unless the
string is already a synthetic unique identifier created by your application
you can't really trust its "uniqueness" for all time. Plenty of people have
built databases using natural unique keys that turned out to be not so unique
or turned out to just be a poor choice for external reasons (think of Social
Security Numbers, for example).

I've had my string unique identifiers corrupted by uppercasing, declared case
insensitive, declared private information that couldn't be leaked, and
declared offensive words that had to be updated. Each of which is a pain to
deal with when it's your primary key.

-- 
greg




view thread (12+ messages)  latest in thread

Message-ID: <87slmohoj8.fsf@stark.xeocode.com>
Permalink:  ../87slmohoj8.fsf@stark.xeocode.com/
Also on:    postgresql.org/message-id/87slmohoj8.fsf@stark.xeocode.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: gsstark@mit.edu, pigwin32@gmail.com
  Subject: Re: Table design question
  In-Reply-To: <87slmohoj8.fsf@stark.xeocode.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox