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 [EMAIL PROTECTED] Phone 1.765.935.4283 Fax 1.765.962.9788 Ray Ontko & Co. Software Consulting Services http://www.ontko.com/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
