Re: Primary keys and composite unique keys(basic question)

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Primary keys and composite unique keys(basic question)
Date: 2021-04-06 02:10:26
Message-ID: CAHyXU0x9_6mkqGm_sWzDtVqd68oisqb9fXSiwxdEfxhqAAiyiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Apr 1, 2021 at 10:26 PM Rob Sargent <robjsargent(at)gmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2021-04-06 02:11:18 Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
Previous Message Michael Schanne 2021-04-05 21:28:06 Re: MultiXactId wraparound and last aggressive vacuum time