Alternative to serial primary key

From: "David Clarke" <pigwin32(at)gmail(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Alternative to serial primary key
Date: 2006-07-06 10:16:42
Message-ID: 12b7ac1e0607060316ub7b5e21i5e8e3bef2504e02c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

I posted a couple of weeks back a question regarding the use of a 100
char column as a primary key and the responses uniformily advised the
use of a serial column. My concern is that the key is effectively
abstract and I want to use the column as a foreign key in other
tables. It occurred to me that if I used a hash function on insert to
generate another column and used that column as the primary key then I
have a value that meets a lot of the requirements for a good key,
including that I can regenerate the exact value from my data,
something that is impossible with a serial id. I also don't have to
index the 100 char column in order to search on the table, I just need
to calculate the hash value and check that against the calculated
column. It does violate the rule that a table shouldn't contain a
column that is calculated from another column in the table but I think
it would still be more effective than a serial id.

Is this a reasonable/normal thing to do? I know postgres contains an
md5() hash function, is this likely to be fast enough to make this an
effective choice? Are there other options? Am I just a noob barking up
the wrong tree? It is getting kind of late and my brain is starting to
hurt.

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Andrew Sullivan 2006-07-06 10:44:06 Re: Alternative to serial primary key
Previous Message Rodrigo De Leon 2006-07-06 07:00:17 Re: week ending