Re: Enforce primary key on every table during dev?
От | marcelo |
---|---|
Тема | Re: Enforce primary key on every table during dev? |
Дата | |
Msg-id | a41226fb-0562-6e3b-a1f4-c9002a37141d@gmail.com обсуждение исходный текст |
Ответ на | Re: Enforce primary key on every table during dev? (Adrian Klaver <adrian.klaver@aklaver.com>) |
Список | pgsql-general |
On 01/03/2018 18:41 , Adrian Klaver wrote: > 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. +1. > >> >>> >>> 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. > > --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus
В списке pgsql-general по дате отправления: