From: | Bill Moran <wmoran(at)collaborativefusion(dot)com> |
---|---|
To: | Moritz Onken <onken(at)houseofdesign(dot)de> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Using PK value as a String |
Date: | 2008-08-12 15:21:36 |
Message-ID: | 20080812112136.72af4bff.wmoran@collaborativefusion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023
From | Date | Subject | |
---|---|---|---|
Next Message | Moritz Onken | 2008-08-12 15:24:50 | Re: Using PK value as a String |
Previous Message | Moritz Onken | 2008-08-12 15:10:24 | Re: Using PK value as a String |