[RobieInteres]

#java #spring #hibernate

Jest jakiś sensowny sposób na zamapowanie enuma jako osobną tabelę ze stałymi id-name tak, żebym nie musiał trzymać w tabeli z użytkownikami magicznych id-ków niezrozumiałych z poziomu bazy?

[zgredinho]

@RobieInteres: a często będziesz zmieniał nazwy płci? ( ͡° ͜ʖ ͡°)

[RobieInteres]

@zgredinho: Raczej nie. Chciałbym tylko, żeby z poziomu bazy było widać, co kryje się np. pod gender_id = 2 ( ͡° ͜ʖ ͡°)

[bylem_bordo]

@RobieInteres: Panie, zacznijmy od tego, że female i male zaraz będziesz musiał przerabiać :). Pracowałem już w takim projekcie, gdzie się okazało, że dwie płcie to jednak za mało. Dodaj tam "other".

[Kresse]

@RobieInteres: EnumType.STRING? Enum jako osobna tabela nie ma sensu, bo enum nie ma własnego cyklu życia i jest ściśle powiązany z kodem.

[RobieInteres]

@Kresse: Tylko właśnie nie wiem, czy dublowanie nazw nie byłoby złamaniem którejś z zasad normalizacji. To mnie najbardziej nurtuje i powstrzymuje przed przechowywaniem tego jako stringa. Oprócz typowego przypadku płci planuję też przechowywanie różnych kategorii i specjalizacji.

[Kresse]

@RobieInteres: Enuma nie możesz redefiniować w runtime (nie można po prostu wrzucić do tabeli nowej wartości i jej używać), dlatego osobna tabela dla niego praktycznie nie daje żadnych korzyści, a wręcz przeciwnie - komplikuje zapytania, bo musisz robić dodatkowego joina, co jest upierdliwe, zwłaszcza jeśli masz kilka enumów. Jedyną wada EnumType.STRING jest trudniejsza zmiana nazwy poszczególnych wartości, ale z reguły robi się to rzadko.
Poza tym pełna normalizacja nie zawsze

[RobieInteres]

@Kresse: Rzeczywiście, masz pełną rację. Taka strategia mocno ułatwi mi pracę w kodzie.

[krasnoludkolo]

@RobieInteres: wrzuć jako string do bazy i tak najłatwiej

[PaaD]

@RobieInteres: łap jeszcze takie rozwiązanie, które zapewnia czytelność dla ludzi i nie psuje wydajności: https://stackoverflow.com/a/17409292/2045440 - sprawdzi się dla silników baz, które ogarniają typ ENUM.
Dodanie nowej wartości wymaga modyfikowanie definicji kolumny, ale przy takich opcjach jak płcie nie spodziewałbym się jakiejś ogromnej pracochłonności przy utrzymywaniu tego zbioru ( ͡° ͜ʖ ͡°)

[nieocenzurowany88]

@RobieInteres ja bym zrobił osobną encję płeć, a w niej jedna kolumna string z nazwami płci i ten string może być kluczem podstawowym tabeli płeć, dzięki czemu jak stworzysz relację między nimi to w tabeli użytkowników w bazie będziesz widział od razu płeć zamiast cyferki, a dodatkowo program jest przyszłościowy gdyż za kilkanaście lat będzie pewnie cała masa płci i będzie je można dodawać do bazy, a jak świat zaszaleje to