Czy enum w bazie danych to dobry pomysł?

Cześć,

Chciałem was zapytać dobrzy koledzy o wasze zdanie. Czy uważacie że przechowywanie enum w bazie danych to dobry pomysł? Wyjaśniam o co mi chodzi:

public enum Typ { A, B }

public class Foo
{
     public int FooId { get; set; }
     public Typ Typ { get; set; }
}

W takiej sytuacji EF wygeneruje tebele z kolumną FooID i kolumną Typ z typem danych Int. Może zamiast tego lepiej zrobić osobną tabele na Typ i w Foo dodać klucz obcy? W mojej sytuacji Foo zawsze będzie miało tylko dwa typy i nigdy nie będzie dodawany nowy typ.

Doradźcie proszę :)

Dzięki!

a nie lepiej takie cos:

public enum Type: int
    {
        A = 1,
        B= 2
    } 

public class Foo
{
     public int FooId { get; set; }
     public int TypId { get; set; }
}

i potem castowac:

var foo = new Foo();
foo.TypId = (int)Type;
 

zawsze zamiast inta uzyj mniejszego zakresu jak byte, gdy tylko niewiele wartosci bedzie przechowwyanych

Właśnie w ten sposób chciałem to zrobić, ale nie wiedziałem czy to jest dobra praktyka, bo wiele "ekspertów" mówi że miejsce na dane jest w bazie danych, nie w kodzie źródłowym. Dzięki za podpowiedź z byte, faktycznie int nie będzie tutaj potrzebny.

BetonPower napisał(a):

Właśnie w ten sposób chciałem to zrobić, ale nie wiedziałem czy to jest dobra praktyka, bo wiele "ekspertów" mówi że miejsce na dane jest w bazie danych, nie w kodzie źródłowym. Dzięki za podpowiedź z byte, faktycznie int nie będzie tutaj potrzebny.

I dlatego o wiele lepiej jest słuchać anonimowych ekspertów z forum... aha... Sam napisałeś, że zakres wartości jest stały i ograniczony, więc po co robić redundantne struktury w bazie danych których istnienie nic nie wnosi? Odwzorowywanie typów wyliczeniowych w strukturach baz danych ma jedynie sens gdy np: robisz aplikację wielojęzyczną i chcesz jego tłumaczenia przechowywać w bazie danych aby mieć możliwość sortowania wyników zapytania po stronie serwera bazy według właśnie tego typu wyliczeniowego w danym języku. Każdym inny przypadek również będzie dobry o ile takie podejście uzasadnia. Twoje działania w tym konkretnym przypadku nie są podyktowane żadnym sensownym uzasadnieniem tylko własnym "widzi mi się".

@szalonyfacet nie lepiej, to rozwiązanie jest bez sensu... Po co deklarujesz typ wyliczeniowy którego praktycznie nie używasz w żadnym innym typie? Aby za każdym razem rzutować na właściwy typ? Przecież pod spodem to i tak będzie typ numeryczny... Użycie typu wyliczeniowego za to zawsze jasno określa jakie wartości dla danej właściwości obiektu są prawidłowe (co można wykorzystać np: implementując w prosty sposób automatyczną walidację przez konwencję).

EF robi to dobrze, nie kombinuj.

Twoje działania w tym konkretnym przypadku nie są podyktowane żadnym sensownym uzasadnieniem tylko własnym "widzi mi się".

Czy forum to jest miejsce na wyładowywanie własnych frustracji? Prosiłem tylko o opinię. Ale odpowiedź uzyskałem - także dzięki.

BetonPower napisał(a):

W takiej sytuacji EF wygeneruje tebele z kolumną FooID i kolumną Typ z typem danych Int. Może zamiast tego lepiej zrobić osobną tabele na Typ i w Foo dodać klucz obcy? W mojej sytuacji Foo zawsze będzie miało tylko dwa typy i nigdy nie będzie dodawany nowy typ.

Tabele się dodaje raczej w sytuacji, gdy mamy zamiar dodawać do niej kolejne rekordy. Zwróć tez uwagę na to, że każda dodatkowa tabela, to dodatkowy join, a to obniża wydajność.