| 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:10:24 |
| Message-ID: | 4D558373-E7B0-40EC-95EF-FDFE7046ABA2@houseofdesign.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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.
moritz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Moran | 2008-08-12 15:21:36 | Re: Using PK value as a String |
| Previous Message | dforums | 2008-08-12 15:06:38 | Re: Distant mirroring |