Enums or Tables?

Question

I am making this a community wiki, as I would appreciate people\'s approach and not necessarily an answer.

I am in the situation where I have a lot of lookup type data

Answer 1

Since C# doesn't allow Enums with string values, so I would suggest a struct with some static strings.

That way, you maintain some Intellisense, but without trying to shoehorn an Enum value on what is a string value in the database.

The other solution I would offer: remove the logic that depends on these values and move to table-based logic. (For instance, if each traunch has a different tax rate, add tax rate as a column in the database rather than a case {} in the code.).

Answer 2

Have a look at my suggestion here How to work with Enums in Entity Framework?

Essentially I use default values sql scripts for core lookup data, with ID's for FK references from other tables, and then I use a simple T4 template to generate my enums for c#. That way the Database is efficient, normalised and correctly constrained, and my c# entities don't have to deal with ID's (Magic numbers).

Its simple quick, easy, and does the job for me.

I use EF4, but you don't need to, could use this approach with whatever technology you use for your entities.

Answer 3

I use both. In Linq to SQL and EF, you just make the column property an enum type. In other frameworks you can usually map the column to an enum property somehow. You can still have an primary key table in the database containing valid enums.

You could also do this with a CHECK constraint in the database, but that tends to tie your data to your application - somebody looking at the database alone wouldn't necessarily know what each value means. Therefore I prefer the hybrid table/enum.

Answer 4

I think an enum is a bad idea. Just given the type of data you show, it's subject to change. Better to have a data base table with ID/Min/Max/Description fields that you load when your app initializes.

Answer 5

First make sure this data is really static. If anything changes, you will have to recompile and redeploy.

If the data is really static, I would go the enum route. You could create a YearlySalaryEnum holding all the values. For string representation I would use a Dictionary with string values and the YearlySalaryEnum as Key. The dictionary can be hold as a static instance in a static class. Usage would be along the lines of (C#):

string highSalary = StaticValues.Salaries[YearlySalaryEnum.High];

Answer 6

One way is to write a formatter that can turn you enum into string representations:

public class SalaryFormatter : IFormatProvider, ICustomFormatter
{
    public object GetFormat(Type formatType)
    {
         return (formatType == typeof(ICustomFormatter)) ? new
         SalaryFormatter () : null;
    }

    public string Format(string format, object o, IFormatProvider formatProvider)
    {
        if (o.GetType().Equals(typeof(Salary)))
        {
            return o.ToString();

            Salary salary = (Salary)o;
            switch (salary)
            {
                case Salary.Low:
                     return "0 - 25K";
                case Salary.Mid:
                     return "25K - 100K";
                case Salary.High:
                     return "100K+";
                default:
                     return salary.ToString();
            }
        }

    return o.ToString();
    }
}

You use the formatter like any other formatter:

Console.WriteLine(String.Format(new SalaryFormatter(), "Salary: {0}", salary));

The formatter can be extented to support different formats through formatting strings, multiple types, localization and so on.