From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Enforce primary key on every table during dev? |
Date: | 2018-03-01 21:41:26 |
Message-ID: | 915390c7-8a2e-108e-2dba-d4f716464de1@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 03/01/2018 01:26 PM, Ron Johnson wrote:
> On 03/01/2018 03:14 PM, Adrian Klaver wrote:
>> On 03/01/2018 01:03 PM, Ron Johnson wrote:
>>> On 03/01/2018 02:32 PM, David G. Johnston wrote:
>>
>>> There's always the "account number", which is usually synthetic.
>>> Credit Card numbers are also synthetic.
>>
>> Actually, no:
>>
>> https://en.wikipedia.org/wiki/Payment_card_number
>>
>> There is a method to the madness, not just random issuance of numbers.
>> It was made it relatively easy for folks to *generate numbers*. Hence
>> the addition of CSC codes.
>
> Right. And how do the issuers generate the individual account
> identifier within their IIN ranges?
Who knows, that is their business, though there is nothing to say they
don't use some sort of internal 'natural' logic. It has been awhile
since we have gone down this rabbit hole on this list, mostly because it
is an issue that is usually left at 'we agree to disagree'. Though the
thing that always strikes me is the assumption that a number/surrogate
key is less 'natural' then some other sort of tag or combination of
tags. Because that is what PK's are, a tag to identify a record.
>
>>
>> ICD numbers are (relatively)
>>> synthetic, too.
>>>
>>> But that doesn't mean we have to use them willy-nilly everywhere.
>
> --
> Angular momentum makes the world go 'round.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2018-03-01 22:05:13 | Re: Enforce primary key on every table during dev? |
Previous Message | Ron Johnson | 2018-03-01 21:26:55 | Re: Enforce primary key on every table during dev? |