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.