Re: Primary keys and composite unique keys(basic question) - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Primary keys and composite unique keys(basic question)
Date
Msg-id CAHyXU0x9_6mkqGm_sWzDtVqd68oisqb9fXSiwxdEfxhqAAiyiQ@mail.gmail.com
Whole thread Raw
In response to Re: Primary keys and composite unique keys(basic question)  (Rob Sargent <robjsargent@gmail.com>)
List pgsql-general
On Thu, Apr 1, 2021 at 10:26 PM Rob Sargent <robjsargent@gmail.com> wrote:
>
> On 4/1/21 8:28 PM, Merlin Moncure wrote:
> >
> > This is one of the great debates in computer science and it is not
> > settled.  There are various tradeoffs around using a composite key
> > derived from the data (aka natural key) vs generated identifiers. It's
> > a complex topic with many facets: performance, organization,
> > validation, and correctness are all relevant considerations.  I would
> > never use UUIDS for keys though.
> >
> > merlin
> >
> >
> And, pray tell, for what exactly would you use universally unique
> identifiers.

I don't disagree that UUID are an ok choice in that scenario.  I'll
tell you what though, that scenario comes up fairly rarely.  However,
there are a couple of alternatives if you're curious.

*) Generate ids from a generator service.  This pattern is fairly
common. It has some downsides (slower, more complicated inserts
mainly) but works well in other ways.  You can mitigate the
performance downsides by allocated identifiers in blocks.

*) Use sequences, but with  a sequence id  added as a composite or
maksed into the integer. This works pretty well in practice.

merlin



pgsql-general by date:

Previous
From: Michael Schanne
Date:
Subject: Re: MultiXactId wraparound and last aggressive vacuum time
Next
From: Tom Lane
Date:
Subject: Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1