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