From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
---|---|
To: | Bill Moran <wmoran(at)collaborativefusion(dot)com> |
Cc: | Steve Atkins <steve(at)blighty(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Using PK value as a String |
Date: | 2008-08-12 15:56:22 |
Message-ID: | 48A1B2A6.4060003@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Bill Moran wrote:
>>>>>> 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.
>> 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.
>>
While we are on this distraction - UUID will sometimes encode "critical"
information such as: 1) The timestamp (allowing users to be compared),
and 2) The MAC address of the computer that generated it.
So, I wouldn't say that UUID truly protects you here unless you are sure
to use one of the UUID formats that is not timestamp or MAC address
based. The main benefit of UUID here is the increased keyspace, so
predicting sequence becomes more difficult.
(Note that an all-random UUID is not better than two pairs of all-random
64-bit integers with a good random number source. :-) )
Cheers,
mark
--
Mark Mielke <mark(at)mielke(dot)cc>
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2008-08-12 16:56:29 | Re: long transaction |
Previous Message | Bill Moran | 2008-08-12 15:48:40 | Re: Using PK value as a String |