Give yourself the option to use either, as I do with this codeset
table:

CREATE TABLE T_CODESET (
CODE_CODE DOM_CODE NOT NULL,
CODE_DESC DOM_STRING1,
CODE_DISPLAY VARCHAR(15),
CODE_GENSTAMP DOM_GENSTAMP,
CODE_PARENT_FK DOM_FK,
CODE_PK DOM_PK,
CODE_RANK SMALLINT,
CODE_SET DOM_CODE NOT NULL
)^

DOM_PK is the integer key; DOM_CODE is a varchar(15) code key. You
can look up a record by its integer key or code. This table resulted
from my desire to use 2-byte codes instead of 4-byte integers where
appropriate for certain fields -- for uber-space saving. CHECKS
ensure referential integrity. There are a lot of benefits to this
code table, which I am happy to expound at length privately if you
are interested (e.g. the 'parent key' relation, the 'display' field,
the 'rank' field for ordering your code sets, etc.). Sadly, I never
got to implement the design because my FB project got canned in
favour of MSSQL, but my tests showed it to be flexible and fast.

Regards,
Andrew Ferguson
-- OK, you've had your fun. Now untie me.

--- In ib-support@y..., "Rob Schuff" <rob@b...> wrote:
> greetings folks,
>
> we are having a spirited discussion at a work about lookup table
and whether
> or not they should have a surrogate primary (integer) or whether
its better
> to just use the lookup value (or an uppercase'd copy of it) as the
primary
> key. I personally have been on both sides of the fence before
(normalize to
> the max or be somewhat pragmatic). Anybody care to share their
opinions?
>
> rob