On Aug 4, 12:12 am, "Jeff Boyce" wrote:
I tend to use Autonumber PKs for most of my tables, much to the dismay of
the "natural key" purists (heh, heh, heh!).

My view: the primary (no pun) consideration is the logical: put a
unique (lowercase) constraint on natural employee number because
failure to do so will result in loss of data integrity, as described
by Jerry Whittle in this thread. Physical considerations are secondary
in my opinion e.g. does my SQL DBMS grant special powers to the
PRIMARY KEY (uppercase) and if so what are they? Does my SQL DBMS
physically repeat the key values for a foreign key and, if so, can I
trust it to cascade the values if they change? Is the performance of
my SQL DBMS so poor that I feel I must restrict myself to a single
eight byte key column? Will my application be successful, hence will
be ported to another platform with different physical considerations?

Jamie.

--