I have an order which has a status (which in code is an Enum). The question is how to persist this. I could:
I'd use an integer mapped to value in another table with the values. You could also then map the enum to the same value, but then you'd have to update in both spots.
#3 is the most "proper" from a database/normalization standpoint. Your status is, in effect, a domain entity that's linked to the order entity.
I suppose it depends on where the data will be retrieved. With #3, you could retrieve the data without relying on your .NET front end. But it is also possible for your database table to get out of sync with the enum code.
Option #2 is certainly the most efficient way to do it for storage... but storage is cheap.
If this is a fixed list (which it seems it is, or else you shouldn't store it as an enum), I wouldn't use #1.
The main reason to use #3 over #2 is for ease of use with self-service querying utilities. However, I'd actually go with a variant of #2: Store the value as an integer and map to an enum on data retrieval. However, also create a table representing the enum type, with the value as the PK and the name as another column. That way it's simple, quick, and efficient to use with your code, but also easy to get the logical value with self-service querying and other uses that don't use your data access code.
hibernate uses integers by default. if your enum is not going to change very often, this is not a bad idea, i think.