Generate Enums from Database or Vice Versa?

Question

I'm trying to figure out which is the the "correct" way to do this. I have a bunch of lookup tables in my database and would like to place an enum on top of those values so, when coding, it's easier to read (as well as not use hard-coded values).

I'm wondering if I should generate my table values based on an existing enumeration or if I should generate my enumeration from my table's values.

EDIT

Based on the first couple of comments, here are some clarifications:

Frequency of changes to the values could be rather frequent as they are intended to be rather dynamic. That being said, a compile will be necessary before adding any of these either way, because the enumeration needs to be updated to expose the new values.

The main reason for this need is because we don't want to tie people down to a specific list of values, we would like the applications to have the ability to add new entries as and when they need to.

In the past, we have generated the data from enumerations, but I'm second guessing myself

Answer 1

We usually generate enums from the database. We use CodeSmith, which allows us to create project files that can easily regenerate the enums as needed.

We've gone the other way occasionally, usually for reporting purposes (when existing enum values are persisted).

And, of course, we have enums whose values are never persisted.

In general the only reason to generate enums from the database is if code needs to make decisions based on them. If you just want to populate a ComboBox and persist the user's choice, don't generate an enum.

Obviously making decisions based on enums (or strings) whose values can change is fragile. You may want to consider including expiration dates (or "from" and "through" dates) in your database schema, so that existing values are not deleted. Filter expired values when populating UI selectors. This also makes it easier to have referential integrity.

As always in C#, you have to be aware that enum values may fall outside of the expected range. Include a default on your switch.

We came up with helper classes for creating cached lookup lists that make these easier to use.

I'm not advocating going down this route. If you have to, this is how we did it.