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: 
If you have to do branching code in your application based on the values in that table, you'd want to represent that table as an enum. If not, making it just another class is fine. 

This is where code generation comes in handy - if you are using something that can generate a table as an enum, you won't have to think about keeping the table and enum in sync - just add your rows to the table, and the next time you generate your business layer, the enum updates itself.
If you have any business logic based on the enum, your main option is to sync then manually. If these rows are also foreign keys for another table (let's say you have a look up table of statuses) you should make the ID type a regular int with a unique index instead of an Identity so that you can easily maintain the ID/Value pairings the same if you have databases in different environments.