Nancy,

You make good points and I often go that route, too. I use xCase which will automatically generate the code for handling cascading updates. So if my users want to change the lookup tables they can and the changes will be cascaded to the main tables. Of course, if the structure of the lookup tables changed it would be more work to deal with that using natural keys. In my experience that rarely happens.

>Hi, Josh.
>
>I respectively suggest that simple look up tables should _definately_ use system keys. I say this as much for selfish reasons: it's so nice to not have to care about the RI issues involved in changing natural keys. For example, my client uses numeric state codes. This is a holdover from decades ago, before two letter state codes. I suspect that eventually they'll standardize on the 2-letter system, which they'll be able to do without having to call me. In anycase, they have their code, too, so they just ignore my ID fields.
>
>IOW, the more I use systems keys the less I can see using natural keys.
>
>One thing I miss about natural keys, though, is in many-to-many intermediate link tables.
>
>>Funny you should post this now. I was just in xCase trying to decide how to deal with this issue. I decided in this case to use natural keys for some simple lookup tables in the application I'm designing. I did this because they'll be doing a lot of ad-hoc reporting and I wanted to make it as simple as possible. In cases where I thought there might be changes to the structure or where more attributes could be added to the lookup table I stuck with artificial keys.