In response to Steve Atkins <steve@blighty.com>:
>
> On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
>
> > In response to Moritz Onken <onken@houseofdesign.de>:
> >
> >>
> >> Am 12.08.2008 um 17:04 schrieb Bill Moran:
> >>
> >>> In response to Moritz Onken <onken@houseofdesign.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@collaborativefusion.com
Phone: 412-422-3463x4023