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

From: Bertrand Mamasam <golgote(at)gmail(dot)com>
To: Hemil Ruparel <hemilruparel2002(at)gmail(dot)com>
Cc: Rob Sargent <robjsargent(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Primary keys and composite unique keys(basic question)
Date: 2021-04-02 07:35:25
Message-ID: CACZ67_WUd3yWjEf-CeVU8NWK62_KsN+n-yssQOdO6mPZ0FW39A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Apr 2, 2021 at 8:57 AM Hemil Ruparel <hemilruparel2002(at)gmail(dot)com>
wrote:

> I used uuid4 for customer ids because i needed to interface with payment
> providers. Is that wrong? All other places except transaction ids, i have
> used serial ints
>
> On Fri 2 Apr, 2021, 8:56 AM 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.
>>
>
ULID perform better than UUID with btree indexes. The first part is based
on a timestamp, so if you don't mind exposing this information, they are a
better choice. There is an implementation for postgres here:
https://github.com/geckoboard/pgulid
Maybe there are others.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2021-04-02 08:29:00 Re: questions about wraparound
Previous Message Pierre Forstmann 2021-04-02 07:06:59 Re: Copy Statistics Tables During Upgrade