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: 
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.
In contrast to Scott Ivey's answer, I prefer (but seldom use) an approach where I only maintain the enums, and on app startup (or maybe on a build event), use Reflection to ensure that table values match my enum values. This doesn't require any code generation, but is susceptible to late detection of referential constraint violations.