Well, here is a dilemma. Should you use an Enum in code or a Lookup Table in the DB for static lookup data. Or should you use both and make sure they match up? And if you do, should you make the tables have an identity INT column?
Depends on the situation.
If you have a lookup table for something that is static (or relatively static – changes maybe once every year or more), then an Enum to Lookup table relationship might be what you need. But, if your list is more than say 10-15 items, I don’t know if it would be best to even have an enum. If you have a lookup table that will get added to a lot (more than once a year) then I don’t think you want to add an enum as you would have to change it and recompile your code on every addition. With the case of frequently changing data or a lot of items in your list, a cached dataset would probably work the best. I think in practice you should lay out ground rules before the start of a project on what business rules have data assumptions and where they will be (data layer, business layer, presentation layer) – that way, there will be no confusion on lookup/seed/static data throughout your project.
If .NET had some way to make sure that your enum and lookup table matched or if you could create the enum from a data table, it would be great. You can dynamically create enums using reflection, but I don’t think that would be the best solution in this scenario.
Here are some other blog posts on the subject
Steve Novoselac's Blog 