>>If there are traps people have hit, I'd like to know them now, before it's
>>too late

>>N.

Me too.

The issues I have with the idea:

1. Personally I find it much easier to debug alpha-numeric codes, rather
than integers.
I've been in the situation before where I have a number, but I'm not sure if
it represents a stock code, raw material, order number, or customer account,
because I scribbled it down in a hurry, without labeling it. With user
defined codes, there is much less of a chance of having a customer account
with the same value PK as a stock code. This just means getting into the
habit of writing more details down, and always working with pen and paper
close at hand.

2. Also, another drawback, is scanning a stock transaction table containing
numbers that mean nothing to me by sight. If, however, the table contains
the stock code themselves, it saves me having to link to the stock table to
see what it actually represents. Now that I'm using Firebird, though (along
with IBExpert), this is actualy becoming less of problem, as it is just as
easy to run a stored proc (with all the stock descriptions looked up), as it
is to look at the data in the table directly.

3. The user generally still wants a stock code, and uniqueness still needs
to be enforced, so the end user ALWAY has to enter a code, so it doesn't
help the end user much, and it doesn't make my life easier either.

The integer based PK DOES sound like a good idea at first, but are there any
real benefits?