As a general rule, a primary key (or any relationship key) should not
contain a value that means something beyond its use in relating entities.
The problem is that if a field describes an object, the day may come when
you want to change the description, but you *never* want to change the field
that identifies the record and relates it to other records.
I can't offer insider's knowledge on speed of int vs string, but it seems
very reasonable to think that an int would be faster. On the other hand, I'm
forced to use strings in my app, and the performance doesn't suffer much so
they must be close.
-Nick
--------------------------------------------------------------------------
Nick Fankhauser nickf@ontko.com Phone 1.765.935.4283 Fax 1.765.962.9788
Ray Ontko & Co. Software Consulting Services http://www.ontko.com/
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Jodi Kanter
Sent: Monday, April 15, 2002 1:56 PM
To: Postgres Admin List
Subject: [ADMIN] string PK vs. interger PK
Can anyone offer some insight as to what should be considered when choosing
between a primary key that is an integer vs. a primary key that is a string
value? Does one or the other affect indexing speed? update speed?
Is a serial integer value better than using a PK that has some "value" in
its meaning but is a string?
Thanks
Jodi
_______________________________
Jodi L Kanter
BioInformatics Database Administrator
University of Virginia
(434) 924-2846
jkanter@virginia.edu