Jak powinienem reprezentować typ wyliczony w relacyjnej bazie danych?

Pracuję nad opracowaniem relacyjnej bazy danych, która śledzi transakcje na urządzeniu, nad którym pracuję dla mojej firmy. Istnieją różne rodzaje transakcji, które mogą wystąpić na urządzeniu, dlatego w jednym z naszych głównych tabel rekordów mamy pole „typ_trans”. Moja grupa postanowiła, że ​​typ tego pola będzie liczbą całkowitą i będzie traktowany jako typ wyliczony. Moja intuicja podpowiada mi, że lepszym pomysłem byłoby uczynienie tego pola ciągiem, aby dane naszej bazy danych były bardziej czytelne i użyteczne. Moi współpracownicy wydają się martwić, że spowodowałoby to więcej kłopotów niż jest to warte. Takie porównania ciągów są zbyt kosztowne, a możliwość literówek jest zbyt dużą barierą.

A zatem, Twoim zdaniem, gdy zajmujesz się polem w relacyjnej bazie danych, która jest zasadniczo wartością wyliczoną, czy lepszą decyzją projektową jest uczynienie tego pola liczbą całkowitą lub łańcuchem? A może jest jakaś inna alternatywa, którą przeoczyłem?

Uwaga: jawnie wyliczone typy nie są obsługiwane przez używaną przez nas bazę danych. Opracowywane przez nas oprogramowanie, które będzie współpracować z tą bazą danych, zostało napisane w języku C ++.

Typy wyliczone powinny być osobną tabelą w bazie danych, która ma numer identyfikacyjny i nazwę ciągu oraz wszelkie inne kolumny, które mogą być przydatne. Następnie każdy typ istnieje jako wiersz w tej tabeli. Następnie w tabeli rejestrujesz transakcje, a pole „trans_Type” powinno być kluczem obcym do klucza tej tabeli referencyjnej. Jest to standardowa praktyka normalizacji bazy danych.

W ten sposób zapisałeś jeden oficjalny ciąg nazwy, możesz użyć porównań liczbowych dla wydajności i mieć spójność referencyjną, że każda transakcja ma prawidłowy typ.

Powszechną praktyką jest tworzenie trans_typestabeli, a następnie przypisywanie jej do tabeli głównej za pomocą klucza obcego o nazwie trans_type_id. To gwarantuje, że twoje rekordy będą odwoływać się tylko do poprawnych wyliczonych typów.

Przykład:

typ_trans
----------
  ID
  Nazwa

transakcje
------------
  ID
  trans_date
  Detale
  trans_type_id (FK na trans_type.id)

Przykładowe dane:

typ_trans

ID | NAZWA
----------
1 | ZATWIERDŹ
2 | ANULUJ


transakcje

ID | trans_date | trans_type_id
---------------------------------
1 | 31.12.2012 | 1
2 | 01.01.2013 | 2)

Jeśli wartości przychodzą do bazy danych jako liczby całkowite, zapisz je w ten sposób. Podczas zapisywania do bazy danych nie ma potrzeby nakładania na siebie konwersji na ciągi. Zawsze możesz odnosić się do tabeli wyszukiwania z wartościami ciąg / tekst (bardziej znormalizowany).

Ma to tę dodatkową zaletę, że aktualizuje wartość ciągu w jednym miejscu zamiast uruchamiać jakąś procedurę aktualizacji. Zamiast 1 = „Czerwony” może być równy „Naprawdę czerwony”

Nie jest to idealne do raportowania wydajności w porównaniu z potrzebą tylko jednej tabeli z wartościami ciągów (Denormalizowane). Indeks w tym polu zapewniłby wystarczającą wydajność.

Większość RDBMS pozwoli na wystarczającą moc. Chociaż twój pomysł na „odczytanie” tabeli w postaci zwykłych danych, dołączenie do niej nie jest niczym wielkim. Po prostu nawyk korzystania z widoku lub podobnego obiektu.

Nie mogę zgodzić się z innymi odpowiedziami na to pytanie, opowiadającymi się za podejściem opartym na osobnej tabeli wyliczeń.

Z pewnością jednak opowiadam się za tym, by nie powtarzać tego, co już powiedziano, więc odniosę się po prostu do zaakceptowanej odpowiedzi na (mniej więcej) to samo pytanie dotyczące przepełnienia stosu: /programming//a/229919 / 114626