Enum czy tabele

Proste pytanie,
mam model, który będzie miał kilka pól złożonych z konkretnym opcji do wyboru.
Przykładowo model human będzie miał do wyboru eyes_color i tutaj opcje do wyboru z góry takie jak blue, green itd.
Następnie te oczy mają mieć jakiś inny display name. Tych pól będzie więcej - początkowo 2-3, potem może dojść ewentualnie parę.
I teraz na szybko wpadły mi 2 pomysły do głowy - wiadomo temat banalny - ale który z nich jest lepszy? Może obydwa są takie same i nie ma żadnej różnicy?

1. W modelu zrobić pole public int Eyes_Color { get; set; }, zrobić zwykły Enum np. eyes_color, a następnie do modelu wstawiać numerek opcji (i potem to samo dla reszty pól). Do wyświetlania innej nazwy zrobić tabelę EnumTranslations i przy pomocy jakiejś statycznej metody pobierać tłumaczenia
2. Zrobić tabelę dla każdej opcji, jak np. Eyes_color, w której będzie Name, Displayname itd, a potem zrobić klucz obcy w tabeli Human.

Tabela.

Tabela do każdej opcji?
Niee...
Zwłaszcza jak tych opcji będą dziesiątki lub więcej, to nie ma sensu.

Jeśli nie będziesz potrzebował dostępu do tych danych bezpośrednio z poziomu SQL (jakieś złączenia, raporty - cokolwiek), a dostęp do wszystkiego zapewni ORM, to wystarczy Enum.
Jeśli jednak chcesz mieć dostęp z poziomu SQL, to dalej Enum + mapowanie konkretnego Enuma do jednej tabeli, która będzie workiem na wszystkie proste słowniki typu Enum.

Używam drugiej opcji, ale w ten sposób:

CREATE TABLE tSyDictHdr (
  IdDict uNAME_S NOT NULL,
  Description uNAME_L NULL)

CREATE TABLE tSyDictLine (
  IdDictFlat dbo.uROW_ID,
  IdDict uNAME_S NOT NULL,
  OrderBy uINT DEFAULT 0 NOT NULL,
  ValueInt uINT NULL,
  Description dbo.uNAME_L NULL
)

tSyDictHdr to nagłówek słownika, czyli nazwa Enum.
tSyDictLine to pozycja słownika, czyli element w Enum.

I teraz tak; ja mam takich słowników 91 (sprawdziłem).
I jeśli miałbym dla każdego z nich mieć osobną tabelę z 1 do 6 wierszami...
No nie.

Tabela pozwala modyfikować kolory oczu bez konieczności wydawania nowej wersji aplikacji. To tak jak z płcią, bez przerwy przybywa kolejnych...

W każdym razie nie tworzyć tabel zawierających same idki z enuma....
Bo jak widzę takie coś w projekcie to mam ochotę kogoś pogonić lagą.

Jesli wystarczy dodać wiersz w bazie i będzie działać, to znaczy, że żaden enum nie jest potrzebny imo. To jest raczej dynamiczny słownik a nie enum. Myśle, ze enumy tworzy się, żeby móc je potem wykorzystać w logice biznesowej a nie tylko tylko na widoku.

Tabela1: Nazwa: EyesColorTable
ID: 1 Name: Niebieske
ID: 2 Name: Czarne

public class EyesColor
{
     public int Id { get; set; }
     public int Value { get; set; }
}

Teraz gdy raptem się okazało, że ktoś ma przezroczyste oczy nie musisz zmieniać całego enuma, tylko dodajesz rekord do tabeli i po sprawie.

To nie jest decyzja techniczna tylko biznesowa. Jeśli ma być możliwość dodawania opcji przez użytkowników, to tabela. Jeśli definiowane przez programistę, to enum.