there does come a point when the overhead of creating smallint/int pks in place of a natural primary key (i.e. the space it takes up for having that extra column which is NOT a part of the data) is greater than a char(2) join vs. an int join. i used to subscribe to the thought that joins should always be done only on int fields. why? what's the real performance gain of that over a char(2)? is it really worth it? and in many cases, having the char(2) meaningful column as the primary key, means you do not have to do as many joins. in some cases, a meaningful column as a primary key can save you numerous table joins. i think each case should be taken on it's own merits rather than a blanket "always use a single non-meaningful long/int/smallint/tinyint as a pk". just in the us states example, if you had a user table, each user was in a state, having a StateID, your query (or what your o/r mapper would produce ;) ) to return a list of users with the state they're in might look like this:

select username, statecode from user inner join state on user.stateid=state.stateid

whereas using a natural pk would make the query

select username, statecode from user

makes for a faster more convenient query and saves on storing an extra field in your database. btw, the us states table was meant to be an example - not as a suggestion to implement :) ditto with the code above.