Syncing referential integrity tables and enums

Question

I ponder this question from time to time, so I thought I'd ask you guys about it.

Let's say I have a database table that looks like this:

Table: Visibility
Id   Value
--   -----
 0   Visible
 1   Invisible
 2   Collapsed

This is just a table for ensuring referential integrity. It is basically an enum stored in the database for the purposes of ensuring that any Visiblity values that appear in other tables are always valid.

Over in my front end, I have some choices.

1. I could query this table and store it in, say, a Dictionary<string, int> or a Dictionary<int, string>.

2. I could write an enum by hand and just manually edit the values in the rare event that there is a change to the table. E.g.,

   public enum Visiblity { Visible, Invisible, Collapsed }

3. Something else????

Which would you advise and why?

Thanks.

Answer 1

For fairly trivial stuff like this, I usually go with an enum. I can identify with you in the sense that I feel it's not completely right... but in my opinion it's the lesser of two evils.

Some additional justification for this: if for some reason a fourth value were to be added, your code would need updating anyway to be able to be able to handle that. While you're at it, it's very little trouble to also update the enum.

Answer 2

In the event that you need to add a new value to the table will this require a coding change in your application to support that new value? If so, make it an enum.

Answer 3

Depending on your database you could make the visibility field an enumerated type. That way the data would have to be one of the options you specified when created the table.