From: | Moritz Onken <onken(at)houseofdesign(dot)de> |
---|---|
To: | |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Using PK value as a String |
Date: | 2008-08-12 15:24:50 |
Message-ID: | 11DAE1B0-3655-49A4-B4D4-9A6F45741059@houseofdesign.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Am 12.08.2008 um 17:21 schrieb Bill Moran:
> In response to Moritz Onken <onken(at)houseofdesign(dot)de>:
>
>>
>> Am 12.08.2008 um 17:04 schrieb Bill Moran:
>>
>>> In response to Moritz Onken <onken(at)houseofdesign(dot)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.
If you are using incrementing integers as pk then you are storing this
data implicitly with your primary key. Using UUIDs is a way to avoid
that.
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2008-08-12 15:36:10 | Re: Using PK value as a String |
Previous Message | Bill Moran | 2008-08-12 15:21:36 | Re: Using PK value as a String |