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.
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 |