Re: question on serial key

From: Jasen Betts <jasen(at)xnet(dot)co(dot)nz>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: question on serial key
Date: 2009-05-26 12:43:09
Message-ID: gvgo4t$akh$1@reversiblemaps.ath.cx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2009-05-22, Brandon Metcalf <brandon(at)geronimoalloys(dot)com> wrote:
> g == gryzman(at)gmail(dot)com writes:
>
> g> you should use it, whenever you need db to keep its own key internally.
> g> Advantage of sequence is also the fact, that you can have the sequence
> g> value used on different columns/tables .
>
> g> My rule of thumb is , in that case: as long as it is a short type (not
> g> of toastable, or/and variable length), and as long as it won't change,
> g> and is unique - I can use it. Otherwise, I use sequence to connect
> g> rows internally for database.
> g> First rule, is because of index access, and the way btree works.
> g> Second is, because update of value will update other rows too - and
> g> HOT won't help you here, so that's not efficient. And also, forcing it
> g> to be unique is harder than.
>
> g> Hth.
>
> That does help. So, in my example of a table consisting of rows for
> each periodic table element, the atomic number would suffice as a
> unique key since, well, it's unique and not going to change. Right?

Well, until some fool* wants to insert a row for deuterium into your
table, and finds that spot taken by hydrogen.

If you can guarantee that you chosen natural key is sufficient and i
s not going to give trouble in the case of marriages, isomerism, twin
birth, isotopes, centegenarians, or some other condition that makes a
mockery of your chosen key then go for it.

*assuming you want it to be fool-proof.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jasen Betts 2009-05-26 13:00:33 Re: quoting values magic
Previous Message Dimitri Fontaine 2009-05-26 12:34:40 Re: How should I deal with disconnects during insert?