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.
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 |