it-swarm.com.de

Sollten statische Daten in einer Datenbank oder woanders gespeichert werden?

Ich arbeite gerade an einer Software und bin mir nicht sicher, welchen Weg ich damit einschlagen soll. Ich muss einige Daten irgendwo auf einem mobilen Gerät speichern. 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 Option enums 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 ein Ressourcenhit sein, der wie eine Verschwendung erscheint, da er sich "nie" ändern wird.

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

Welches ist hier der richtige Designpfad?

Anmerkung : Mit 'Nie' ändern meine ich, dass es sich selten ändern wird. Bei den fraglichen Daten handelt es sich um ein Modell einer Reihe von Regierungsstandards, sodass sie sich möglicherweise irgendwann in der Zukunft ändern, aber nicht regelmäßig und auch nicht automatisch aktualisiert werden, da eine Änderung der Standards durchaus möglich ist eine Änderung unserer Anforderungen auslösen.

22
CurlyPaul

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 die Größe erhöhen.
Die XML-Datei wäre auch ein bisschen übertrieben und erhöht auch die Größe.

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

19
Knerd

wird es sich nie ä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. Wochentagsnamen), sind gut für den Code geeignet.

Daten, die sich praktisch nie ändern (z. B. der DNS-Name Ihres Servers), können auch im Code verwendet 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), sind wahrscheinlich am besten an einem leicht zu ändernden Ort, z. B. in einem lokalen Konfigurationsspeicher (SQLite oder XML, macht keinen wirklichen Unterschied).

Der Speicher spielt keine Rolle - wenn er sich nie oder kaum ändert, können Sie ihn beim Programmstart einlesen und als Programmdaten zwischenspeichern. Wenn sich in dem unwahrscheinlichen Fall jemals etwas ändern muss, ist ein Neustart der App weniger eine große Sache.

13
gbjbaanb

Normalerweise sind die Dinge, die sich "nie ändern", die ersten, die sich ändern ...
Ob Sie eine Datenbank oder ein anderes externes System (wie 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 eine Datenbank habe, und dies ist sinnvoll (sagen wir, die Daten müssen möglicherweise von Personen geändert werden, die keinen Dateisystemzugriff auf den Server haben, auf dem die Anwendung bereitgestellt wird, oder Es läuft auf mehreren Computern und die Konfiguration muss zwischen ihnen synchron 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.

5
jwenting

Die Frage, die nach Daten gestellt werden muss, ist nicht, 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 es sich ändert, wer sollte es ändern:

  • der Autor der Software: Geben Sie es in den Code ein
  • endbenutzer: Haben Sie eine Option auf der GUI
  • jemand anderes (z. B. ein Systemintegrator, ein Internationalisierungsdienst usw.): Datenbanktabelle, Datei oder was auch immer sinnvoll ist (einschließlich manchmal einer Erweiterungs-API).

Dienstag sollte im Allgemeinen eine Aufzählung sein, nicht weil es sich nie ändern kann. Aber wenn ein verrückter Diktator das Kommando übernommen hat und verlangt, dass der Dienstag nach ihm benannt wird, müssen Sie als Software-Autor dies ändern (oder den Haien gefüttert werden).

Sie möchten nicht, dass alle Benutzer in Konfigurationsdateien oder unklaren Datenbanktabellen stöbern müssen, um dieses Schicksal zu vermeiden ...

4
soru

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

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

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

Es ist an sich nichts Falsches daran, Länder als Entitäten zu modellieren und in der Datenbank zu speichern. Aber in den meisten Fällen ist das zu kompliziert. Länder ändern sich nicht oft. Wenn sich der Name eines Landes ändert, ist es praktisch ein neues Land. Wenn eines Tages kein Land 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 namens AvailableCountry einzuführen:

Diese verfügbaren Länder können Entitäten in einer Datenbank, Datensätze in einem JSON oder einfach eine fest codierte Liste in Ihrem Code sein. (Dies hängt davon ab, ob das Unternehmen über eine Benutzeroberfläche einen einfachen Zugriff darauf 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, Nachschlagetabellen sowohl als Wertobjekte als auch als Entitäten zu modellieren.

Übrigens, stellen Sie sicher, dass Sie im Kommentarbereich nach einige ernsthafte Diskussionen über den Artikel suchen.

2
Songo

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 die Möglichkeit, eigene Änderungen vorzunehmen.

Jede andere Art der Änderung der Datenstruktur erfordert wahrscheinlich ein Update der App. Dies ist also kein Vorteil.

2
JeffO