Question

I have an application that I need to query lifetables (for insurance calculation).
I was thinking about using XML to store the data, but thought it was a little big, but maybe a little small for using a full-fledged database. So I chose to use SQLite.

In my application, I have enums defining a few different things. For example, GENDER.Male, GENDER.Female. and JOBTYPE.BlueCollar, JOBTYPE.WhiteCollar. etc etc.

I have some methods that look like this: (example)

FindLifeExpectancy(int age, GENDER gender);
FindDeathRate(int age, JOBTYPE jobType);

So my question is: How do you model enums in a database? I don’t think it is best practice to use 0 or 1 in the database to store JOBTYPE because that would be meaningless to anyone looking at it. But if you used nvarchar, to store “BlueCollar”, there would be a lot of duplicate data.

I don’t think GENDER or JOBTYPE should have an entire class, or be apart of the entity model because of the little information they provide.

How is this normally done?

Thanks.

Answer 1

I prefer to statically map my enums in my program to a lookup table in my database. I rarely actually use the lookup table to do a join. As an example I might have the following tables:

Gender
GenderID  Name
1         Male
2         Female

Accounts
AccountID  GenderID  FirstName  LastName
1          1         Andrew     Siemer
2          2         Jessica    Siemer

And in code I would then have my enum defined with the appropriate mapping

public enum Gender
{
    Male = 1,
    Female = 2
}

Then I can use my enum in code and when I need to use the enum in a LINQ to SQL query I just get its physical value like this

int genderValue = (int)Enum.Parse(typeof(Gender), Gender.Male));

This method may make some folks out there a bit queezy though given that you have just coupled your code to values in your database! But this method makes working with your code and the data that backs that code much easier. Generally, if someone swaps out the ID of a lookup table, you are gonna be hosed in some way or another given that it is mapped across your database any how! I prefer the readability and ubiquitous nature of this design though.