Storing codes vs. human-intelligible values - best practice?

In a pre-existing project, many tables reference domain (lookup)
tables of the general structure:
# COL_NM (column name) -- a primary key containing a human-
intelligible value; max varchar length varies by table, but typically
no longer than 30 characters
* COL_CD (column code) -- a not null field with a unique
constraint, typically an integer with a length of 1-2 digits.
o COL_DES (column description) -- an optional description field;
could be up to 255 chars

The child tables referencing these domain tables use the COL_NM human
intelligible values rather than the less storage intensive COL_CD
(since it is unique and not null, it could also be used by a
referencing child table).

In a new project, it's been suggested to me that I continue to store
COL_NM values rather than COL_CD values in the child tables with these
rationales:
-- It's better to use COL_NM because, for anyone directly querying the
child tables, COL_NM means something to a human. COL_CD doesn't
(unless someone has a really good memory).
-- "Oracle can handle it"

However:
-- The new child tables will have orders of magnitude more rows than
the child tables in the old database; so, although "Oracle can handle
it", storage may be an issue, etc.
-- I've always thought it was a best practice to store short codes
rather than longer human-intelligible values.
-- As far as I can tell, few if any users will be querying the child
tables directly; and if they were, they could join to the domain table
to get the human intelligible values

Wondering if anyone with more experience than me (most people reading
this group, probably) have any opinions on the best way to proceed.
What other factors do I need to consider in making a choice?

Thanks.

Dana

(A few project constraints that may or may not be relevant to my
question (dictated to me, so they're non-negotiable) are:
-- Can't use check constraints (and wouldn't want to; easier to update
values in a domain table than change a constraint)
-- Can't use Oracle product-specific domains; we're typically asked
not to use vendor-specific features))
.

Relevant Pages

  • RE: Display mutliple 1-1 tables in DataGrid?
    ... I do not have multiple children and the data is text so there is ... no aggregate function that I can use in referencing the child item. ... I cannot find any way to make the DataGrid display data from both ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Delete query taking long time to execute
    ... table using its primary key in where clause, it takes more than 30 seconds to ... Is it because of constraints or any other sort. ... referencing this table, the size of the referencing tables, and the ... each of the 12 "Child" tables has to be ...
    (microsoft.public.sqlserver.mseq)
  • Re: SQL, related records (quotes)
    ... Did you just forget the foreign key constraint ... > establish that 'hierarchies' can just contain hierarchies ... Starting with an empty relation with just a key constraint on 'child', ... vertex involving itself as a root node of a hierarchy. ...
    (comp.databases.theory)
  • Re: SQL, related records (quotes)
    ... CONSTRAINT CHECK, ... child parent ... Multiple trees are easily mapped to branches of one root ... Starting with an empty relation with just a key constraint on 'child', ...
    (comp.databases.theory)
  • Re: Storing codes vs. human-intelligible values - best practice?
    ... tables of the general structure: ... constraint, typically an integer with a length of 1-2 digits. ... The child tables referencing these domain tables use the COL_NM human ... you won't likely gain anything with shorter codes, ...
    (comp.databases.oracle.server)