tags:

views:

170

answers:

7
+2  Q: 

Enums or Tables?

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 fields, that do not change. An example would be:

Yearly Salary
Option: 0 - 25K
Option: 25K - 100K
Option: 100K +

I would like to have these options easily available through an enum, but would also like to textual values available in the DB, as I will do reporting on the textual values and not a ID. Also, since they are static I do not want to be making calls to the DB.

I was thinking duplicating this in an enum and table, but would like to hear some alternate thoughts.

Thanks

+5  A: 

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.

No Refunds No Returns
That was an example, it will not change. I like your approach anyway, how would you persist the data throughout the application. Will there be any performance issues being that the data is not needed for 99% of the app?
Dustin Laine
If this data is rarely accessed, you can just keep it in a static class that is initialized the first time you ask for the data (lazy initialization). Just make sure that locks are in place so only one thread can access that data at a time. This will eliminate any start-up slowdowns. If you don't want to wait the first time you access the data, you could also add loading the data to a low priority work queue to get loaded when the goes idle for a moment or two (or loaded immediately if it's needed earlier)
Eclipse
If it really won't change and you don't have a data base you can just store it in your app.config file in a custom section.
No Refunds No Returns
really, I don't understand the **OR** idea here. If **texts** changes it should be in the **DB**, but when you **load** it from DB you associate it with a **enumeration**. This is the sense of enumeration to be used in such situations.
serhio
+1  A: 

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.

Aaronaught
A: 

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];
Johannes Rudolph
What about for SQL reporting? How would that get resolved using a enum only approach.
Dustin Laine
Initialize the dictionary from DB, pretty easy. If the datatype behind the enum is an integer, mapping it to a db column is straightforward. As Aaron has pointed out, many ORMs can do so out of the box.
Johannes Rudolph
A: 

Use both enum(for code) and DB texts- for GUI presentation.

So, if you will always have 3 option use an enum LowSalary, MiddleSalary and HighSalary, store your texts in the DB and switch your texts in the GUI corresponding to your property enum value.

serhio
+1  A: 

Use both, And you should investigate the CodeDOM. using this you can write code generation routines that allow the compilation process to automatically generate an assembly or class with these enums in it, by reading the database. This way you get to let the database drive, but you are not making calls to the database everytime you access an instance of the enum...

Charles Bretana
A: 

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

richardtallent
A: 

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.

Kristoffer Kjeldby
i think they will not appreciate the idea. I don't know why, but having a Database table for this 3 variables is seen better by them...
serhio