Dlaczego miałbyś przechowywać wyliczenie w DB?

Widziałem wiele pytań, takich jak to , proszących o porady, jak przechowywać wyliczenia w DB. Ale zastanawiam się, dlaczego miałbyś to zrobić. Powiedzmy, że mam byt Personz genderpolem i Genderwyliczeniem. Następnie moja tabela osób ma płeć kolumny.

Poza oczywistym powodem wymuszania poprawności, nie rozumiem, dlaczego miałbym utworzyć dodatkową tabelę, genderaby zmapować to, co już mam w swojej aplikacji. I tak naprawdę nie lubię tego powielania.

Weźmy inny przykład, który jest mniej przepełniony koncepcjami i oczekiwaniami. Mam tutaj wyliczenie i jest to zestaw priorytetów dla błędu.

Jaką wartość przechowujesz w bazie danych?

Tak, mogę być przechowywanie 'C', 'H', 'M'oraz 'L'w bazie danych. Lub 'HIGH'tak dalej. Ma to problem z ciągami danych. Znany jest zestaw prawidłowych wartości, a jeśli nie przechowujesz tego zestawu w bazie danych, praca z nim może być trudna.

Dlaczego przechowujesz dane w kodzie?

Masz List<String> priorities = {'CRITICAL', 'HIGH', 'MEDIUM', 'LOW'};lub coś w tym rodzaju w kodzie. Oznacza to, że masz różne mapowania tych danych do właściwego formatu (wstawiasz wszystkie Caps do bazy danych, ale wyświetlasz je jako Critical). Twój kod jest teraz również trudny do zlokalizowania. Związano reprezentację pomysłu bazy danych z ciągiem przechowywanym w kodzie.

Gdziekolwiek musisz uzyskać dostęp do tej listy, musisz mieć duplikację kodu lub klasę z szeregiem stałych. Żaden z nich nie jest dobrym rozwiązaniem. Nie należy również zapominać, że istnieją inne aplikacje, które mogą korzystać z tych danych (które mogą być napisane w innych językach - aplikacja internetowa Java ma używany system raportowania Crystal Reports i dane wsadowe do zadania wsadowego Perl ). Aparat raportujący musiałby znać prawidłową listę danych (co się stanie, jeśli nie ma nic zaznaczonego w 'LOW'priorytecie i musisz wiedzieć, że jest to prawidłowy priorytet dla raportu?), A zadanie wsadowe będzie zawierało informacje o tym, co jest ważne wartości są.

Hipotetycznie, to może powiedzieć „jesteśmy sklep single-język - wszystko jest napisane w języku Java” i mieć jeden .jar, który zawiera tę informację - ale teraz oznacza to, że aplikacje są ściśle sprzężone ze sobą i że .jar zawierającego dane. Musisz wydać część raportującą i część dotyczącą aktualizacji wsadowej wraz z aplikacją internetową za każdym razem, gdy zachodzi zmiana - i mam nadzieję, że to wydanie będzie przebiegać płynnie dla wszystkich części.

Co się stanie, gdy szef chce innego priorytetu?

Twój szef przyszedł dzisiaj. Jest nowy priorytet - CEO. Teraz musisz przejść i zmienić cały kod oraz dokonać ponownej kompilacji i ponownego wdrożenia.

Dzięki metodzie „wyliczania w tabeli” aktualizujesz listę wyliczania, aby uzyskać nowy priorytet. Cały kod, który pobiera listę, pobiera ją z bazy danych.

Dane rzadko są samodzielne

W przypadku priorytetów klucze danych do innych tabel, które mogą zawierać informacje o przepływach pracy lub o tym, kto może ustawić ten priorytet lub co innego.

Wracając do płci, jak wspomniano w pytaniu: Płeć ma link do używanych zaimków: he/his/himi she/hers/her... i chcesz uniknąć twardego kodowania tego w samym kodzie. A potem przychodzi twój szef i musisz dodać, że masz 'OTHER'płeć (dla uproszczenia) i musisz powiązać tę płeć z they/their/them... i twój szef widzi, co ma Facebook i ... no tak.

Ograniczając się do łańcucha danych o ciągach ciągłych zamiast do tablicy wyliczeniowej, musisz teraz zreplikować ten ciąg w szeregu innych tabel, aby zachować ten związek między danymi a innymi bitami.

Co z innymi magazynami danych?

Niezależnie od tego, gdzie to przechowujesz, istnieje ta sama zasada.

• Możesz mieć plik priorities.propz listą priorytetów. Czytasz tę listę z pliku właściwości.

• Możesz mieć bazę danych magazynu dokumentów (taką jak CouchDB ), która zawiera wpis dla enums(a następnie napisać funkcję sprawdzania poprawności w JavaScript ):

  {
     "_id": "c18b0756c3c08d8fceb5bcddd60006f4",
     "_rev": "1-c89f76e36b740e9b899a4bffab44e1c2",
     "priorities": [ "critical", "high", "medium", "low" ],
     "severities": [ "blocker", "bad", "annoying", "cosmetic" ]
  }
  

• Możesz mieć plik XML ze schematem:

  <xs:element name="priority" type="priorityType"/>
  
  <xs:simpleType name="priorityType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="critical"/>
      <xs:enumeration value="high"/>
      <xs:enumeration value="medium"/>
      <xs:enumeration value="low"/>
    </xs:restriction>
  </xs:simpleType>
  

Podstawowa idea jest taka sama. Sam magazyn danych jest miejscem, w którym należy przechowywać i egzekwować listę prawidłowych wartości. Umieszczając go tutaj, łatwiej jest zrozumieć kod i dane. Nie trzeba się martwić o defensywnie sprawdzanie co masz za każdym razem (jest to górna przypadek? Czy niższa? Dlaczego istnieje chriticaltyp w tej kolumnie? Etc ...), bo wiesz, co otrzymujesz z powrotem magazyn danych jest dokładnie to, czego oczekuje magazyn danych, że w przeciwnym razie wyślesz - i możesz zapytać magazyn danych o listę prawidłowych wartości.

Na wynos

Zestaw prawidłowych wartości to dane , a nie kod. Ty nie musisz dążyć do DRY kodu - ale problem powielania jest, że jesteś powielanie danych w kodzie, a nie respektując jego miejsce jako danych i przechowywanie go w bazie danych.

Ułatwia pisanie wielu aplikacji w magazynie danych i pozwala uniknąć instancji, w których trzeba będzie wdrożyć wszystko, co jest ściśle związane z danymi - ponieważ nie połączono kodu z danymi.

Ułatwia to testowanie aplikacji, ponieważ nie trzeba ponownie testować całej aplikacji po CEOdodaniu priorytetu - ponieważ nie ma kodu, który dbałby o rzeczywistą wartość priorytetu.

Możliwość niezależnego rozumowania kodu i danych ułatwia znajdowanie i naprawianie błędów podczas konserwacji.

Który z nich, według Ciebie, może częściej powodować błędy podczas czytania zapytania?

select * 
from Person 
where Gender = 1

Lub

select * 
from Person join Gender on Person.Gender = Gender.GenderId
where Gender.Label = "Female" 

Ludzie tworzą tabele enum w SQL, ponieważ uważają, że te ostatnie są bardziej czytelne - co prowadzi do mniejszej liczby błędów podczas pisania i obsługi SQL.

Możesz uczynić płeć ciągiem bezpośrednio w Person, ale wtedy będziesz musiał spróbować wyegzekwować wielkość liter. Możesz także zwiększyć trafienie pamięci dla tabeli i czas zapytania ze względu na różnicę między ciągami i liczbami całkowitymi w zależności od tego, jak wspaniale jest twoja baza danych w optymalizacji rzeczy.

Nie mogę uwierzyć, że ludzie jeszcze o tym nie wspominali.

Klucz obcy

Utrzymując enum w bazie danych, i dodanie klucza obcego w tabeli, która zawiera wartość enum Ci zapewnić , że żaden kod kiedykolwiek wejdzie niepoprawne wartości dla tej kolumny. Pomaga to w integralności danych i jest najbardziej oczywistym powodem, dla którego IMO powinna mieć tabele dla wyliczeń.

Jestem w obozie, który się z tobą zgadza. Jeśli zachowasz wyliczenie płci w kodzie i tblGender w bazie danych, możesz mieć problemy z czasem konserwacji. Musisz udokumentować, że te dwa podmioty powinny mieć te same wartości, a zatem wszelkie zmiany, które wprowadzisz w jednym, musisz wprowadzić również w drugim.

Następnie musisz przekazać wartości wyliczeniowe do procedur przechowywanych w następujący sposób:

create stored procedure InsertPerson @name varchar, @gender int
    insert into tblPeople (name, gender)
    values (@name, @gender)

Ale pomyśl, jak byś to zrobił, gdybyś trzymał te wartości w tabeli bazy danych:

create stored procedure InsertPerson @name varchar, @genderName varchar
    insert into tblPeople (name, gender)
    select @name, fkGender
    from tblGender
    where genderName = @genderName --I hope these are the same

Na pewno relacyjne bazy danych są tworzone z myślą o sprzężeniach, ale które zapytanie jest łatwiejsze do odczytania?

Oto kolejne przykładowe zapytanie:

create stored procedure SpGetGenderCounts
    select count(*) as count, gender
    from tblPeople
    group by gender

Porównaj to z tym:

create stored procedure SpGetGenderCounts
    select count(*) as count, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender
    group by genderName --assuming no two genders have the same name

Oto jeszcze jedno przykładowe zapytanie:

create stored procedure GetAllPeople
    select name, gender
    from tblPeople

Pamiętaj, że w tym przykładzie będziesz musiał przekonwertować komórkę płci w wynikach z int na wyliczenie. Te konwersje są jednak łatwe. Porównaj to z tym:

create stored procedure GetAllPeople
    select name, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender

Wszystkie te zapytania są mniejsze i łatwiejsze w utrzymaniu, gdy przechodzisz do pomysłu, aby trzymać definicje wyliczeń poza bazą danych.

Chciałbym utworzyć tabelę Płeć z tego powodu, że można jej użyć do analizy danych. Mógłbym wyszukać wszystkie osoby płci męskiej lub żeńskiej w bazie danych, aby wygenerować raport. Im więcej sposobów przeglądania danych, tym łatwiej będzie znaleźć informacje o trendach. Oczywiście jest to bardzo proste wyliczenie, ale w przypadku skomplikowanych wyliczeń (takich jak kraje świata lub stany) ułatwia generowanie specjalistycznych raportów.

Najpierw musisz zdecydować, czy baza danych będzie kiedykolwiek używana tylko przez jedną aplikację, czy może istnieć możliwość korzystania z niej przez wiele aplikacji. W niektórych przypadkach baza danych jest niczym innym jak formatem pliku dla aplikacji (bazy danych SQLite mogą być często używane w tym zakresie). W takim przypadku bit powielający definicję wyliczenia jako tabelę często może być w porządku i może mieć większy sens.

Jednak gdy tylko rozważysz możliwość posiadania dostępu do bazy danych przez wiele aplikacji, wówczas tabela dla wyliczenia ma sens (inne odpowiedzi zawierają bardziej szczegółowe informacje na temat tego, dlaczego). Inną rzeczą do rozważenia będzie Ty lub inny programista, którzy chcą przyjrzeć się surowym danym bazy danych. Jeśli tak, można to uznać za inne zastosowanie aplikacji (tylko takie, w którym miernikiem laboratoryjnym jest surowy SQL).

Jeśli masz wyliczenie zdefiniowane w kodzie (dla czystszego kodu i sprawdzania czasu kompilacji), a także tabelę w bazie danych, zaleciłbym dodanie testów jednostkowych w celu sprawdzenia, czy oba są zsynchronizowane.

Jeśli masz wyliczenie kodu, które jest używane do napędzania logiki biznesowej w kodzie, nadal powinieneś utworzyć tabelę reprezentującą dane w bazie danych z wielu powodów wyszczególnionych powyżej / poniżej. Oto kilka wskazówek, które pomogą zapewnić synchronizację wartości DB z wartościami kodu:

1. Nie zmieniaj pola ID w tabeli w kolumnę Tożsamość. Uwzględnij identyfikator i opis jako pola.

2. Zrób coś innego w tabeli, co pomoże programistom wiedzieć, że wartości są półstatyczne / powiązane z wyliczeniem kodu. We wszystkich innych tabelach przeglądowych (zwykle tam, gdzie użytkownicy mogą dodawać wartości) zazwyczaj mam LastChangedDateTime i LastChangedBy, ale brak ich w tabelach związanych z wyliczaniem pomaga mi pamiętać, że są one zmieniane tylko przez programistów. Dokumentuj to.

3. Utwórz kod weryfikacyjny, który sprawdza, czy każda wartość w wyliczeniu znajduje się w odpowiedniej tabeli i czy tylko te wartości znajdują się w odpowiedniej tabeli. Jeśli masz zautomatyzowane „testy kondycji” aplikacji, które są uruchamiane po kompilacji, w tym miejscu. Jeśli nie, uruchom kod automatycznie podczas uruchamiania aplikacji, ilekroć aplikacja działa w środowisku IDE.

4. Tworzenie produkcji dostarcza skrypty SQL, które robią to samo, ale z poziomu bazy danych. Prawidłowo utworzone pomogą również w migracji środowiska.

Zależy również od tego, kto uzyskuje dostęp do danych. Jeśli masz tylko jedną aplikację, może być w porządku. Jeśli dodasz w hurtowni danych lub systemie raportowania. Będą musieli wiedzieć, co oznacza ten kod, jaka jest ludzka wersja kodu, którą można zmodyfikować.

Zwykle tabela typów nie byłaby duplikowana w kodzie jako wyliczenie. Możesz załadować tabelę typów do listy, która jest buforowana.

Class GenderList

   Public Shared Property UnfilteredList
   Public Shared Property Male = GetItem("M")
   Public Shared Property Female = GetItem("F")

End Class

Często typ przychodzi i odchodzi. Potrzebna byłaby data dodania nowego typu. Dowiedz się, kiedy określony typ został usunięty. Wyświetlaj tylko w razie potrzeby. Co jeśli klient chce „transpłciowości” jako płci, ale inni klienci tego nie robią? Wszystkie te informacje najlepiej przechowywać w bazie danych.