Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 152FD650195 for ; Tue, 12 Aug 2008 12:21:36 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 29029-04 for ; Tue, 12 Aug 2008 12:21:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id 132B1650054 for ; Tue, 12 Aug 2008 12:21:28 -0300 (ADT) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 12 Aug 2008 11:21:26 -0400 id 00056407.48A1AA77.00010B67 Date: Tue, 12 Aug 2008 11:21:36 -0400 From: Bill Moran To: Moritz Onken Cc: pgsql-performance@postgresql.org Subject: Re: Using PK value as a String Message-Id: <20080812112136.72af4bff.wmoran@collaborativefusion.com> In-Reply-To: <4D558373-E7B0-40EC-95EF-FDFE7046ABA2@houseofdesign.de> References: <18986.60888.qm@web25807.mail.ukl.yahoo.com> <48A15ECF.5030203@sime.com> <87od3ywg4n.fsf@oxford.xeocode.com> <0673579A-B049-4619-B6E4-EE427FB0DDBA@globalinn.com> <1343069D-263F-4D99-BF7E-269C8F0E7F1F@houseofdesign.de> <20080812110416.8e0d6e1c.wmoran@collaborativefusion.com> <4D558373-E7B0-40EC-95EF-FDFE7046ABA2@houseofdesign.de> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/128 X-Sequence-Number: 31009 In response to Moritz Onken : > > Am 12.08.2008 um 17:04 schrieb Bill Moran: > > > In response to Moritz Onken : > > > >> 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@collaborativefusion.com Phone: 412-422-3463x4023