views:

799

answers:

6

I have an order which has a status (which in code is an Enum). The question is how to persist this. I could:

  1. Persist the string in a field and then map back to enum on data retrieval.
  2. Persist this as an integer and then map back to enum on data retrieval.
  3. Create separate table for enum value and do a join on data retrieval.

Thoughts?

A: 

hibernate uses integers by default. if your enum is not going to change very often, this is not a bad idea, i think.

PeterP
A: 

What database are you using? Most modern databases have enum fields.

Apreche
A: 

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.

sfossen
A: 

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.

Jeff Martin
+1  A: 

#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.

Harper Shelby
+5  A: 

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.

Jonathan
+1, I'd also setup an FK to ensure that the integer is a valid enum value.
LukeH
Yes, plus, having it as an FK helps with discoverability for self-service query tools.
Jonathan