Czy dane statyczne powinny być przechowywane w bazie danych czy gdzie indziej?

Obecnie pracuję nad jakimś oprogramowaniem i nie jestem pewien, którą drogę wybrać. Mam jakieś dane do przechowywania gdzieś na urządzeniu mobilnym. Dane nigdy się nie zmienią i mają hierarchiczną relację i zostaną wykorzystane do wypełnienia wyświetlacza. Istnieje rozsądna ilość tych danych.

Mam następujące opcje:

1. Zestaw wyliczeń / obiektów
2. Plik XML
3. Wbudowana baza danych SQLite

W tym konkretnym przypadku myślę, że opcja wyliczania jest najmniejsza, ale wyczuwam zapach z danych osadzonych w takim kodzie.

Plik XML wydaje mi się najbardziej sensowny, ale parsowanie go będzie trafieniem w zasoby, które wydaje się marnotrawstwem, ponieważ „nigdy” się nie zmieni.

Baza danych powinna zapewniać mniejszą wydajność, ale wydaje się, że przesada w przypadku danych statycznych.

Która ścieżka jest tutaj poprawna?

Uwaga: Przez zmianę „Nigdy” mam na myśli, że rzadko się zmienia. Dane, o których mowa, są modelem zestawu standardów rządowych, więc mogą się zmienić w pewnym momencie w przyszłości, ale nie będzie regularnie i nie będzie automatycznie aktualizować naszego oprogramowania, ponieważ zmiana standardów mogłaby równie dobrze wywołać zmianę naszych wymagań.

Użyłbym do tego obiektu.

Powiedziałeś, że dane nigdy się nie zmienią, więc możesz łatwo przechowywać je w aplikacji. Baza danych byłaby nadmierna i zwiększyłaby rozmiar.
Plik XML byłby też trochę przesadny, a także zwiększa rozmiar.

Więc moim zdaniem najlepszą opcją byłby wyliczenie lub przedmiot.

czy to się nigdy nie zmieni, czy zmieni? To pytanie, na które naprawdę musisz odpowiedzieć, zanim uzyskasz dobrą odpowiedź.

Dane statyczne, które nigdy się nie zmieniają (np. Nazwy dni tygodnia) są przydatne w kodzie;

Dane, które praktycznie nigdy się nie zmieniają (np. Nazwa twojego serwera dns) są również dobre do wprowadzenia w kodzie, jeśli trzeba je zmienić, to tak rzadkie, że aktualizacja kodu jest w porządku.

Dane, które się nie zmieniają, ale mogą (np. Opóźnienie między okresowymi odświeżeniami) są prawdopodobnie najlepsze w łatwo zmienialnej lokalizacji, takiej jak lokalny sklep z konfiguracjami (sqlite lub xml, nie robi żadnej różnicy)

Pamięć nie ma większego znaczenia - jeśli się nigdy nie zmieni lub prawie nigdy się nie zmieni, możesz odczytać to wszystko przy starcie programu i zapisać w pamięci podręcznej jako dane programu. Jeśli w mało prawdopodobnym przypadku kiedykolwiek trzeba to zmienić, ponowne uruchomienie aplikacji nie jest tak wielkim problemem.

Zwykle rzeczy, które „nigdy się nie zmieniają”, zmieniają się jako pierwsze ...
Niezależnie od tego, czy korzystasz z bazy danych, czy z innego systemu zewnętrznego (np. Pliku konfiguracyjnego), nie ma to większego znaczenia, o ile można łatwo i szybko uzyskać do niego dostęp w razie potrzeby.
Zwykle używam tabeli bazy danych, jeśli i tak mam już bazę danych, i ma to sens (powiedzmy, że dane muszą zostać zmienione przez osoby, które nie mają dostępu do systemu plików do serwera, na którym aplikacja jest wdrożona, lub działa na wielu komputerach i konfiguracja musi być zsynchronizowana między nimi).
Oczywiście baza danych nie może pomieścić wszystkiego. Na przykład poświadczenia bazy danych będą musiały być przechowywane w innym miejscu, najprawdopodobniej w pliku konfiguracyjnym.

Pytanie o dane nie polega na tym, czy ulegną one zmianie; prawdopodobnie nie wiesz, a nawet gdybyś wiedział, odpowiedź byłaby myląca.

Pytanie, które należy zadać, kiedy to się zmieni, kto powinien to zmienić:

• autor oprogramowania: umieść go w kodzie
• użytkownik końcowy: ma opcję w GUI
• ktoś inny (np. integrator systemu, usługa internacjonalizacji itp.): tabela bazy danych, plik lub cokolwiek innego (w tym czasem rozszerzenie API).

Wtorek powinien zasadniczo być wyliczeniem, ponieważ nie może się nigdy zmienić. Ale ponieważ jeśli szalony dyktator przejmie władzę i zażąda, aby wtorek został nazwany jego imieniem, Ty jako autor oprogramowania będziesz musiał to zmienić (lub nakarmić rekiny).

Nie chcesz, aby wszyscy użytkownicy musieli kopać pliki konfiguracyjne lub zaciemniać tabele bazy danych, aby uniknąć tego losu ...

Istnieje szansa, że ​​Twoje dane mogą wymagać zmiany, nawet jeśli podmioty, które reprezentują dane w prawdziwym świecie, mogą tego nie zmienić. Musisz zdecydować, czy warto dołączyć osobny plik tekstowy, który można zaktualizować bez aktualizacji całej aplikacji.

Przykłady:

1. Błąd typograficzny / literówka.
2. Przypadkowe pominięcie.
3. Oferuj dane w innym języku.
4. Oferuj sposób wprowadzania własnych zmian przez użytkownika.

Jakikolwiek inny rodzaj zmiany struktury danych prawdopodobnie będzie wymagał aktualizacji aplikacji, więc nie przynosi to żadnych korzyści.

Oryginalnie napisałem tę odpowiedź na to pytanie podczas stackoverflow , ale myślę, że ta sama odpowiedź dotyczy również tego pytania.

Artykuł Mathiasa Verraesa mówi o twoim problemie tutaj . Mówi o oddzielaniu obiektów wartości w modelu od pojęć służących interfejsowi użytkownika.

Cytując z artykułu na pytanie, czy modelować kraje jako podmioty, czy wycenić obiekt:

Nie ma w sobie nic złego w modelowaniu krajów jako podmiotów i przechowywaniu ich w bazie danych. Ale w większości przypadków to komplikuje sprawy. Kraje nie zmieniają się często. Kiedy zmienia się nazwa kraju, w rzeczywistości jest to praktycznie nowy kraj. Jeśli któregoś dnia kraj już nie istnieje, nie można po prostu zmienić wszystkich adresów, ponieważ możliwe, że kraj został podzielony na dwa kraje.

Zasugerował inne podejście do wprowadzenia nowej koncepcji o nazwie AvailableCountry:

Te dostępne kraje mogą być jednostkami w bazie danych, rekordami w JSON, a nawet po prostu zakodowaną listą w kodzie. (To zależy od tego, czy firma chce mieć do nich łatwy dostęp za pośrednictwem interfejsu użytkownika).

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Wydaje się więc, że istnieje trzecie rozwiązanie, które polega na modelowaniu tabel wyszukiwania jako obiektów wartości i encji.

BTW, upewnij się, że sprawdziłeś sekcję komentarzy, aby uzyskać poważne dyskusje na temat tego artykułu.

Rzeczy do rozważenia:

• Jak statyczne są dane? Jeśli to się nigdy nie zmieni, to powinno mieszkać w obiekcie. Aby zmienić dane, konieczne może być ponowne skompilowanie i ponowne wdrożenie. Czy jesteś zadowolony z przeniesienia w celu wprowadzenia niewielkiej zmiany?

• Jeśli jest to aplikacja internetowa i masz ją jako część pliku web.config, czy jesteś zadowolony z ponownego uruchamiania aplikacji po wprowadzeniu zmian w tych danych?

• Jeśli umieścisz go w bazie danych, zawsze możesz buforować go po stronie klienta (aplikacja komputerowa) lub po stronie serwera (usługa lub strona internetowa). Baza danych może być dobrym rozwiązaniem IMO.