Najlepszy sposób na odniesienie do statycznej bazy danych w kodzie?

Wiele aplikacji zawiera „dane statyczne”: dane, które tak naprawdę nie zmieniają się w trakcie życia aplikacji. Na przykład może istnieć lista obszarów sprzedaży, która prawdopodobnie będzie stałą listą w dającej się przewidzieć przyszłości.

Często zdarza się, że te dane statyczne znajdują się w tabeli bazy danych (często dlatego, że chcesz się do nich odwoływać w kluczach obcych innych tabel). Prosta przykładowa tabela będzie miała identyfikator, który będzie używany jako klucz podstawowy i opis. Na przykład twoja tabela SalesArea będzie miała (przynajmniej) kolumnę SalesAreaId i kolumnę SalesAreaDescription.

Teraz w kodzie możesz nie chcieć traktować każdego wiersza tabeli tak samo. Na przykład możesz chcieć ustawić domyślny Obszar Sprzedaży na niektórych ekranach, podać różne liczby dla niektórych obszarów lub ograniczyć to, co użytkownicy mogą robić w innych obszarach.

Jaki jest najlepszy sposób odwoływania się do tych danych statycznych w kodzie? Czemu?

1. Zakoduj opisy w swoim kodzie. Użyj tego, aby wyszukać SalesAreaId z bazy danych, gdy jej potrzebujesz.
2. Zakoduj identyfikatory w swoim kodzie. Skorzystaj z tego, aby wyszukać opis SalesAreaDescription, gdy go potrzebujesz.
3. Dodaj kolumnę do tabeli dla każdego celu, np. Kolumnę „IsDefaultOnProductLaunchScreen” i tak dalej (może być ich wiele).
4. Coś innego.

Czy są jakieś inne specjalne uwagi, które powinienem wziąć pod uwagę, mając do czynienia ze statycznymi danymi z bazy danych? Na przykład, nadając tym tabelom specjalną nazwę?

Co powiesz na załadowanie ich do pamięci podręcznej (zwykle implementowanej jako tabela skrótów) podczas uruchamiania aplikacji? Jeśli to zrobisz, nie musisz nawet sprawdzać bazy danych (cóż, nie więcej niż raz).

Sugerowałbym także unikanie twardego kodowania czegokolwiek. Dodaj domyślne wskaźniki (początkowo w tabeli DB, a także w strukturze pamięci podręcznej) dla ekranów, które wymagają ustawień domyślnych. Aby wyszukiwać pliki bez defauiltu, spróbuj zapisać klucze, które będą wyszukiwane w pliku konfiguracji lub właściwości, jeśli możesz.

Alternatywą dla DB lub twardego kodowania jest użycie pliku konfiguracyjnego odczytanego podczas uruchamiania. Następnie możesz przechowywać te dane w strukturze tylko do odczytu w kodzie.

W rzadkim (ale nie niemożliwym) przypadku, w którym edytujesz te dane, musisz ponownie uruchomić aplikację. Jeśli nie jest to możliwe, możesz napisać bardziej złożony menedżer konfiguracji, który sprawdza zmiany w pliku konfiguracyjnym przy każdym dostępie do danych, jest to w rzeczywistości całkiem wydajne, ponieważ wystarczy sprawdzić znacznik czasu w pliku, a następnie unieważnić wszystkie dane jeśli plik zostanie zaktualizowany.

Jeśli dane odnoszą się do istniejących danych w bazie danych, prawdopodobnie równie skuteczne jest dodanie ich do bazy danych, jak i dodanie jej do kodu. Jeśli tak się nie stanie, zwykle kusi mnie, aby „raz wziąć tę kulę” i umieścić ją w kodzie do pierwszej zmiany.

Często okazuje się, że to, co uważamy za statyczne, nie jest, a kiedy tak się dzieje, nie trzeba czekać na wydanie kodu, aby wprowadzić zmiany. Gdy tylko to się stanie, umieść go w bazie danych i napisz stronę administratora, aby dokonać dalszych aktualizacji.

Na przykład, jeśli masz już Obszary sprzedaży w DB, dodaj tam opis, nie buduj tabeli skrótów, aby powiązać dane bazy danych z listami zakodowanymi na stałe. Ale jeśli nie zbudujesz tabeli skrótów Obszarów sprzedaży, ale bądź gotowy, za pierwszym razem, gdy ktoś zmieni opis lub doda nowy Obszar sprzedaży, przenieś go do bazy danych.

Dlaczego nie po prostu wszystko napisać na sztywno? Głównym problemem, który zawsze miałem, jest odwoływanie się do wartości statycznych z bazy danych w kodzie aplikacji. To jedno, jeśli budujesz bezpośrednio listę rozwijaną lub coś z wartości statycznych, ale co, jeśli logika aplikacji zależy od wartości z bazy danych?

W prostej aplikacji mam obecnie listę stanów edycji fragmentów treści: Szkic, Opublikowane, Zarchiwizowane.

Elementy treści muszą być traktowane w różny sposób w zależności od stanu, w jakim się znajdują. Gdybym miał zachować dane o tym stanie w DB, odpowiednio o wartościach 1, 2, 3, jak bym sprawdził, czy coś jest w wersji roboczej stan?

if (content.State == 1)
czy
if (content.State == "Draft")?

Właśnie zapisałem wartości na stałe!
To samo, jeśli używasz tabeli pamięci podręcznej / skrótu: nadal musisz użyć wartości zapisanej w kodzie jako klucza do wyszukiwania danych.

Jakie są wady podejścia kodującego?

Podobnie do tego, co powiedział FrustratedWithFormsDesigner, zwykle odbywa się to za pomocą pamięci podręcznej, ponieważ oznacza to, że zawsze trzeba ładować dane statyczne tylko raz, ale jest zgodny ze wzorcem OAOO, co oznacza, że ​​nie definiujemy danych w dwóch miejscach (baza danych i Twój kod).

Wiem, że NHibernate ORM oferuje tę funkcjonalność poprzez pamięć podręczną drugiego poziomu . Możesz nakazać buforowanie danych z określonej tabeli i powiedzieć, że jest ona tylko do odczytu. Zostanie załadowany za pierwszym razem, gdy będzie wymagany, i nie trafi później do bazy danych, nawet jeśli uzyskasz dostęp do danych z wielu sesji.

Jest to przedwczesna optymalizacja w najgorszym przypadku.

Po pierwsze, każdy nowoczesny DBMS pobierze dane z małych tabel z prędkością błyskawicy i wszystkie mają algorytmy buforowania od dobrego do doskonałego (im więcej zapłaciłeś za DBMS, tym lepsze buforowanie!). Optymalizujesz więc coś, co zużywa minimalne zasoby.

Po drugie, masz bardzo małe doświadczenie z rzeczywistymi aplikacjami biznesowymi, jeśli wyobrażasz sobie, że „strefa sprzedaży” to dane statyczne. Mogą ulec zmianie przy każdej zmianie dyrektora marketingu lub dyrektora generalnego. Kierujesz się w świat bólu dwa lata później.

Są tylko dwa sposoby, aby przejść tutaj: -

Przechowuj go w bazie danych i uzyskuj dostęp do danych za pomocą „normalnego” sql.

Przechowuj go w fantazyjnym pliku konfiguracyjnym XML (możliwy dostęp poprzez REST lub SOAP), który można łatwo edytować za każdym razem, gdy nastąpi „strategiczna zmiana polityki”.

To zależy od tego, co robisz z danymi. Jeśli jest to lista czegoś, zwykle przeciągam ją do tablicy. Jeśli lista musi się rozwijać w innej wersji, łatwo jest po prostu dodać ją do bazy danych i zmienić kod, aby obsłużyć dodatkowe dane w tablicy (co może nawet nie być konieczne w zależności od kodu, np. Wyświetlenie listy za pomocą dla pętli za pomocą górnej granicy tablicy). Jeśli jest to lista ustawień, zwykle koduję je na stałe, ponieważ zwykle nie ma ich wiele i jest łatwiejsze i szybsze niż używanie instrukcji SQL. Jeśli jest to ustawienie, które użytkownik może zmienić i chcę zapisać wybór do kolejnych uruchomień, utworzę tabelę, która będzie używana jako rejestr i po prostu wyciągam poszczególne wpisy do zmiennych w razie potrzeby.

Wiem, że ta odpowiedź została zaakceptowana, ale chciałem opowiedzieć o tym, jak to zrobiliśmy w moim ostatnim sklepie z programistami, w którym staraliśmy się maksymalnie ograniczyć operacje wejścia / wyjścia bazy danych.

Użyliśmy plików dołączanych po stronie serwera dla możliwie największej liczby struktur danych typu wyszukiwania. Służyło to głównie do nawigacji w witrynie (w tym nawigacji podrzędnej), ale wykorzystaliśmy ją również do tylu rozwijanych menu i pól wyboru, jak to możliwe (stany, kraje, kategorie).

Początkowo pobraliśmy wszystkie te dane z bazy danych. Ponieważ daliśmy klientowi widget administratora, mogą oni dowolnie zmieniać te dane i nigdy nie daliśmy się zaskoczyć drobnymi zmianami. Przez większość czasu dane te prawie nigdy się nie zmieniały, ale okazjonalnie by się zmieniały.

Zawsze szukaliśmy szybszych czasów ładowania. Postanowiliśmy więc wdrożyć jak najwięcej statycznych plików tekstowych po stronie serwera, jak to możliwe. Zrobiliśmy to po stronie widgetu administratora. Za każdym razem, gdy aktualizowana jest tabela bazy danych, regenerujemy odpowiedni statyczny plik tekstowy. To zapewniło nam bardzo elastyczne i szybkie środowisko.

Moim rozwiązaniem tego problemu, które może nie działać we wszystkich sytuacjach, jest powiązanie statycznych danych z bazy danych z zakodowanym na stałe enum. Ponieważ problem wynika z powiązania danych dynamicznych (bazy danych) z logiką statyczną (kodem), jawnie (i luźno) to powiązanie, mając tabelę bazy danych powiązaną z enum. Dawny:

LooseDBCodeBinding (database table)
   ID : Int32 (key)
   Name : String
   HardCodedTypeID : Int32

// in code:
public enum LooseDBCodeBinding
{
   TYPE_1 = 1,
   TYPE_2 = 2,
   TYPE_3 = 3 // etc...
}

Następnie napisz interfejs użytkownika, który pozwala łatwo przeglądać listę LooseDBCodeBindingrekordów i mapować je na LooseDBCodeBinding enumwartości (w tym obsługę „zepsutych” powiązań). Następnie możesz programować wokół enumi projektować bazę danych wokół klucza tabeli, a tylko ta jedna tabela ma wiedzę na temat obu kontekstów.