Re: Using PK value as a String
От | Steve Atkins |
---|---|
Тема | Re: Using PK value as a String |
Дата | |
Msg-id | 233F1248-E3EA-4572-9310-4E4BC13995DE@blighty.com обсуждение исходный текст |
Ответ на | Re: Using PK value as a String (Bill Moran <wmoran@collaborativefusion.com>) |
Ответы |
Re: Using PK value as a String
|
Список | pgsql-performance |
On Aug 12, 2008, at 8:21 AM, Bill Moran wrote: > In response to Moritz Onken <onken@houseofdesign.de>: > >> >> Am 12.08.2008 um 17:04 schrieb Bill Moran: >> >>> In response to Moritz Onken <onken@houseofdesign.de>: >>> >>>> We chose UUID as PK because there is still some information in an >>>> integer key. >>>> You can see if a user has registered before someone else >>>> (user1.id < >>>> user2.id) >>>> or you can see how many new users registered in a specific period >>>> of >>>> time >>>> (compare the id of the newest user to the id a week ago). This is >>>> information >>>> which is in some cases critical. >>> >>> So you're accidentally storing critical information in magic values >>> instead of storing it explicitly? >>> >>> Good luck with that. >> >> How do I store critical information? I was just saying that it easy >> to get some information out of a primary key which is an incrementing >> integer. And it makes sense, in some rare cases, to have a PK which >> is some kind of random like UUIDs where you cannot guess the next >> value. > > I just repeated your words. Read above "this is information which > is in > some cases critical." > > If I misunderstood, then I misunderstood. > I think Moritz is more concerned about leakage of critical information, rather than intentional storage of it. When a simple incrementing integer is used as an identifier in publicly visible places (webapps, ticketing systems) then that may leak more information than intended. Cheers, Steve
В списке pgsql-performance по дате отправления: