Sollten statische Daten in einer Datenbank oder anderswo gespeichert werden?

Ich arbeite gerade an einer Software und bin mir nicht sicher, welchen Weg ich damit einschlagen soll. Ich habe Daten, die ich irgendwo auf einem Mobilgerät speichern kann. Die Daten ändern sich nie und haben eine hierarchische Beziehung. Sie werden zum Auffüllen der Anzeige verwendet. Es gibt eine angemessene Menge dieser Daten.

Ich habe folgende Möglichkeiten:

1. Eine Reihe von Aufzählungen / Objekten
2. Eine XML-Datei
3. Die eingebettete SQLite-Datenbank

In diesem speziellen Fall denke ich, dass die Aufzählungsoption am wenigsten funktioniert, aber ich bekomme einen Geruch von den Daten, die so in den Code eingebettet sind.

Die XML-Datei ist meiner Meinung nach am sinnvollsten, aber das Parsen wird zu einem Ressourcen-Hit, der wie eine Verschwendung erscheint, da er sich "nie" ändern wird.

Die Datenbank sollte weniger Leistungseinbußen aufweisen, scheint jedoch für statische Daten zu viel zu sein.

Welches ist hier der richtige Designpfad?

Hinweis: Mit "Niemals" meine ich, dass es sich selten ändern wird. Bei den fraglichen Daten handelt es sich um ein Modell einer Reihe von behördlichen Standards, sodass sie sich möglicherweise zu einem späteren Zeitpunkt ändern, jedoch nicht regelmäßig erfolgen und unsere Software auch nicht automatisch aktualisieren werden, da eine Änderung der Standards durchaus möglich ist eine Änderung unserer Anforderungen auslösen.

Ich würde dafür ein Objekt verwenden.

Sie sagten, dass sich die Daten niemals ändern werden, sodass Sie sie problemlos in der Anwendung speichern können. Die Datenbank wäre übertrieben und würde größer werden.
Die XML-Datei wäre auch ein bisschen übertrieben und vergrößert sich auch.

Meiner Meinung nach wäre die beste Option eine Aufzählung oder ein Objekt.

Wird es sich niemals ändern oder wird es sich ändern? Das ist die Frage, die Sie wirklich beantworten müssen, bevor Sie eine gute Antwort erhalten.

Statische Daten, die sich nie ändern (z. B. Namen von Wochentagen), gehören in den Code.

Daten, die sich praktisch nie ändern (z. B. der DNS-Name Ihres Servers), können auch in den Code eingefügt werden. Wenn sie geändert werden müssen, ist dies so selten, dass eine Code-Aktualisierung in Ordnung ist.

Daten, die sich nicht ändern, aber möglicherweise (z. B. Zeitverzögerung zwischen regelmäßigen Aktualisierungen), sollten am besten an einem leicht zu ändernden Ort gespeichert werden, z. B. in einem lokalen Konfigurationsspeicher (SQLite oder XML).

Die Speicherung spielt keine Rolle - wenn sie sich nie oder kaum ändert, können Sie sie beim Programmstart einlesen und als Programmdaten zwischenspeichern. Sollte sich der unwahrscheinliche Fall ändern müssen, ist ein Neustart der App keine große Sache.

Normalerweise ändern sich zuerst die Dinge, die sich "nie ändern" ...
Ob Sie eine Datenbank oder ein anderes externes System (z. B. eine Konfigurationsdatei) verwenden, spielt keine Rolle, solange bei Bedarf einfach und schnell darauf zugegriffen werden kann.
Ich verwende normalerweise eine Datenbanktabelle, wenn ich ohnehin bereits über eine Datenbank verfüge, und dies ist sinnvoll (beispielsweise müssen die Daten möglicherweise von Personen geändert werden, die keinen Dateisystemzugriff auf den Server haben, auf dem die Anwendung implementiert ist, oder sie wird auf mehreren Computern ausgeführt) und die Konfiguration muss synchron zwischen ihnen gehalten werden).
Natürlich kann eine Datenbank nicht alles enthalten. Datenbankanmeldeinformationen müssen beispielsweise an einer anderen Stelle gespeichert werden, höchstwahrscheinlich in einer Konfigurationsdatei.

Bei der Frage nach Daten geht es nicht darum, ob sie sich ändern werden. Sie wissen es wahrscheinlich nicht, und selbst wenn Sie es tun würden, wäre die Antwort wahrscheinlich irreführend.

Die Frage ist, wenn sich etwas ändert, wer es ändern soll:

• Der Software-Autor: Geben Sie den Code ein
• der Endbenutzer: hat eine Option auf der GUI
• Eine andere Person (z. B. ein Systemintegrator, ein Internationalisierungsdienst usw.): eine Datenbanktabelle, eine Datei oder was auch immer sinnvoll ist (einschließlich manchmal einer Erweiterungs-API).

Dienstag sollte in der Regel eine Enumeration sein, da es sich nie ändern kann. Aber wenn ein verrückter Diktator das Kommando übernahm und forderte, dass der Dienstag nach ihm benannt wird, müssten Sie als Software-Autor dies ändern (oder den Haien verfüttert werden).

Sie möchten nicht, dass sich alle Benutzer in Konfigurationsdateien oder in verdeckten Datenbanktabellen vertiefen müssen, um dieses Schicksal zu vermeiden ...

Es besteht die Möglichkeit, dass sich "Ihre" Daten ändern müssen, obwohl die Entitäten, die die Daten in der realen Welt darstellen, dies möglicherweise nicht tun. Sie müssen entscheiden, ob es sich lohnt, eine separate Textdatei einzuschließen, die aktualisiert werden kann, ohne die gesamte App zu aktualisieren.

Beispiele:

1. Tippfehler / Rechtschreibfehler.
2. Versehentliches Auslassen.
3. Bieten Sie die Daten in einer anderen Sprache an.
4. Bieten Sie dem Benutzer eine Möglichkeit, seine eigenen Änderungen vorzunehmen.

Jede andere Art von Datenstrukturänderung erfordert wahrscheinlich ein Update der App, sodass dies keinen Nutzen bringt.

Ich habe diese Antwort ursprünglich für diese Frage auf stackoverflow geschrieben , aber ich denke, dass die gleiche Antwort auch für diese Frage gilt.

Es ist ein Artikel von Mathias Verraes , dass die Gespräche über Ihr Problem hier . Er spricht über das Trennen von Wertobjekten im Modell von Konzepten, die der Benutzeroberfläche dienen.

Zitiert aus dem Artikel, wenn gefragt wird, ob Länder als Entitäten oder als Wertobjekt modelliert werden sollen:

Es ist grundsätzlich nichts Falsches daran, Länder als Entitäten zu modellieren und in der Datenbank zu speichern. Aber in den meisten Fällen sind das überkomplizierte Dinge. Länder ändern sich nicht oft. Wenn sich der Name eines Landes ändert, ist es praktisch ein neues Land. Wenn ein Land eines Tages nicht mehr existiert, können Sie nicht einfach alle Adressen ändern, da das Land möglicherweise in zwei Länder aufgeteilt wurde.

Er schlug einen anderen Ansatz vor, um ein neues Konzept einzuführen AvailableCountry:

Diese verfügbaren Länder können Entitäten in einer Datenbank, Datensätze in einer JSON oder auch einfach eine fest codierte Liste in Ihrem Code sein. (Das hängt davon ab, ob das Unternehmen einen einfachen Zugriff über eine Benutzeroberfläche wünscht.)

<?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];
    }
}

Es scheint also eine dritte Lösung zu geben, die darin besteht, Look-Up-Tabellen sowohl als Wertobjekte als auch als Entitäten zu modellieren.

Stellen Sie übrigens sicher, dass Sie in den Kommentaren nach ernsthaften Diskussionen über den Artikel suchen.

Dinge, die man beachten muss:

• Wie statisch sind die Daten? Wenn es sich nie ändern wird, sollte es im Objekt leben. Um die Daten zu ändern, müssen Sie möglicherweise neu kompilieren und erneut bereitstellen. Sind Sie mit einer Neuverteilung für eine geringfügige Änderung zufrieden?

• Wenn es sich um eine Webanwendung handelt und Sie sie als Teil der Datei web.config haben, können Sie die Anwendung dann gerne neu starten, wenn Sie Änderungen an diesen Daten vornehmen?

• Wenn Sie es in eine Datenbank stellen, können Sie es immer auf Client-Seite (Desktop-Anwendung) oder Server-Seite (Dienst oder Website) zwischenspeichern. Datenbank könnte eine gute Lösung sein IMO.