Re: Using PK value as a String

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Steve Atkins <steve(at)blighty(dot)com>
Cc: PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Using PK value as a String
Date: 2008-08-12 15:48:40
Message-ID: 20080812114840.8f7468ed.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

In response to Steve Atkins <steve(at)blighty(dot)com>:

>
> On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
>
> > 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.
> >
>
> 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.

Then I did misunderstand.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Mielke 2008-08-12 15:56:22 Re: Using PK value as a String
Previous Message Steve Atkins 2008-08-12 15:36:10 Re: Using PK value as a String