"David Clarke" <[EMAIL PROTECTED]> writes: > is it really that big an issue these days to have a 100 character primary > key? Are there postgres-specific implications for either approach?
It's exactly the same size issue as ever. A 20% increase in space usage is a 20% performance hit in certain types of queries regardless of how fast or cheap your hardware has become. This is an issue where reasonable people differ quite vociferously so you may get contradictory responses. But really it depends heavily on the exact circumstances and requires a judgement call based on experience. Any time someone tries to sum it up with a blanket rule it's going to be wrong some of the time. But that said I also tend to tilt towards creating serial ids. Unless the string is already a synthetic unique identifier created by your application you can't really trust its "uniqueness" for all time. Plenty of people have built databases using natural unique keys that turned out to be not so unique or turned out to just be a poor choice for external reasons (think of Social Security Numbers, for example). I've had my string unique identifiers corrupted by uppercasing, declared case insensitive, declared private information that couldn't be leaked, and declared offensive words that had to be updated. Each of which is a pain to deal with when it's your primary key. -- greg ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster