As long as we're beating a dead horse...

Since the example in the article doesn't provide the DDL, you might assume that the key has been (or could be) defined across strDescription and strCategory (who names their columns like this?).  In all likelyhood, those who use MUCKs are going to declare the key on the intID column, but let's just pretend that this person knows enough to at least declare a unique constraint on the real key...

If that's the case then you also have to assume that there is a valid reason (we're still pretending here) for wanting to maintain the customer.state separate from postal.state.  In which case, the two categories would be stored in separate tables in a properly designed database and you could have 'California' in each one.

This just highlights another logical problem with MUCKs.  If a "code" in a real database truly can be applied to multiple entity types, then it's easy enough to declare multiple FK relationships.  In a MUCK that has a category column it is very messy to accomplish the same thing.