From: | Brandon Metcalf <brandon(at)geronimoalloys(dot)com> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: question on serial key |
Date: | 2009-05-22 15:04:25 |
Message-ID: | Pine.LNX.4.58L.0905221003190.17654@cedar.geronimoalloys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
s == sam(at)samason(dot)me(dot)uk writes:
s> On Fri, May 22, 2009 at 08:41:46AM -0500, Brandon Metcalf wrote:
s> > I am looking for criteria on deciding whether or not to use a serial
s> > (auto-incrementing) key for rows in a table.
s> Wow, that's the second time today someone asked that!
s> > Intuitively, it's pretty clear to me when a serial index is called
s> > for. Is there a succinct set of guidelines that one could go by?
s> Not that I'm aware of; it's a fuzzy design choice with benefits and
s> costs for either option. There are lots of people who arbitrarily
s> pick one side which tends to make things worse, using one or the other
s> *exclusively* will add complication. General terms to search for are
s> Natural keys vs. Surrogate keys.
The search terms help. I wasn't searching for the right thing and
finding very little information.
--
Brandon
From | Date | Subject | |
---|---|---|---|
Next Message | artacus | 2009-05-22 15:23:07 | Re: Aggregate Function to return most common value for a column |
Previous Message | Vick Khera | 2009-05-22 14:56:51 | Re: Tuning resource parameters for a logging database. |