Les données statiques doivent-elles être stockées dans une base de données ou ailleurs?

Je travaille sur un logiciel en ce moment et je ne sais pas quel chemin prendre avec cela. J'ai des données à stocker quelque part sur un appareil mobile. Les données ne changeront jamais, ont une relation hiérarchique et seront utilisées pour remplir l'affichage. Il existe une quantité raisonnable de ces données.

J'ai les options suivantes:

1. Un ensemble d'énumérations / objets
2. Un fichier XML
3. La base de données SQLite embarquée

Dans ce cas particulier, je pense que l'option enums est le moins de travail, mais je reçois une odeur des données intégrées dans le code comme ça.

Le fichier XML est le plus logique, je pense, mais l'analyse sera un hit de ressource qui semble être un gaspillage car il ne changera jamais.

La base de données devrait fournir moins de résultats de performance, mais semble exagérée pour les données statiques.

Quel est le chemin de conception correct ici?

Remarque: Par «jamais» changer, je veux dire qu'il changera rarement. Les données en question sont un modèle d'un ensemble de normes gouvernementales, donc elles pourraient bien changer à un moment donné dans le futur, mais cela ne sera pas régulier et ne mettra pas automatiquement à jour notre logiciel non plus car un changement dans les normes pourrait bien déclencher un changement dans nos exigences.

J'utiliserais un objet pour ça.

Vous avez dit que les données ne changeront jamais, vous pouvez donc facilement les stocker dans l'application. La base de données serait exagérée et augmenterait la taille.
Le fichier XML serait également un peu exagéré et augmente également la taille.

Donc, à mon avis, la meilleure option serait une énumération ou un objet.

cela ne changera-t-il jamais ou changera-t-il? C'est la question à laquelle vous devez vraiment répondre avant d'obtenir une bonne réponse.

Les données statiques qui ne changent jamais (par exemple les noms des jours de la semaine) sont bonnes à saisir dans le code;

Les données qui ne changent pratiquement jamais (par exemple, le nom de votre serveur DNS) sont également bonnes à entrer dans le code, si elles doivent être modifiées, elles sont si rares qu'une mise à jour de code est correcte.

Les données qui ne changent pas, mais qui pourraient (par exemple, le délai entre les rafraîchissements périodiques) sont probablement meilleures dans un emplacement facilement modifiable, comme un magasin de configuration local (sqlite ou xml, ne fait aucune différence réelle)

Le stockage est peu important - s'il ne change jamais ou presque jamais, vous pouvez tout lire au démarrage du programme et le mettre en cache en tant que données de programme. Si, dans le cas peu probable où cela devait changer, un redémarrage de l'application n'est pas vraiment un problème.

Habituellement, les choses qui "ne changent jamais" sont les premières à changer ...
Que vous utilisiez une base de données ou un autre système externe (comme un fichier de configuration) importe peu, tant qu'il est facilement et rapidement accessible en cas de besoin.
J'ai tendance à utiliser une table de base de données si j'ai déjà une base de données de toute façon, et cela a du sens (par exemple, les données doivent éventuellement être modifiées par des personnes qui n'ont pas accès au système de fichiers sur le serveur sur lequel l'application est déployée, ou elle s'exécute sur plusieurs machines et la configuration doit être synchronisée entre eux).
Bien sûr, une base de données ne peut pas tout contenir. Les informations d'identification de la base de données, par exemple, devront être stockées ailleurs, probablement un fichier de configuration.

La question à poser pour toute donnée n'est pas de savoir si elle va changer; vous ne savez probablement pas, et même si vous le saviez, la réponse serait probablement trompeuse.

La question à se poser est, quand elle change, qui devrait la changer:

• l'auteur du logiciel: mettez-le dans le code
• l'utilisateur final: avoir une option sur l'interface graphique
• quelqu'un d'autre (par exemple un intégrateur de système, un service d'internationalisation, etc.): table de base de données, fichier ou tout ce qui a du sens (y compris parfois une API d'extension).

Le mardi devrait généralement être une énumération non pas parce qu'il ne peut jamais changer. Mais parce que si un dictateur fou a pris les choses en main et a exigé que mardi soit nommé d'après lui, vous, en tant qu'auteur du logiciel, devrez le changer (ou être donné aux requins).

Vous ne voudriez pas que tous vos utilisateurs aient à fouiller dans des fichiers de configuration ou des tables de base de données obscures pour éviter ce sort ...

Il est possible que «vos» données aient besoin de changer même si les entités que les données représentent dans le monde réel ne le sont pas. Vous devez décider si cela vaut la peine d'inclure un fichier texte distinct d'une sorte qui peut être mis à jour sans mettre à jour l'application entière.

Exemples:

1. Erreur typographique / faute d'orthographe.
2. Omission accidentelle.
3. Offrez les données dans une autre langue.
4. Offrez à l'utilisateur un moyen d'effectuer ses propres modifications.

Tout autre type de changement de structure de données nécessitera probablement une mise à jour de l'application, ce n'est donc pas un avantage.

À l'origine, j'ai écrit cette réponse pour cette question sur stackoverflow , mais je pense que la même réponse s'applique également à cette question.

Il y a un article de Mathias Verraes qui parle de votre problème ici . Il parle de Séparer les objets de valeur dans le modèle des concepts qui servent l'interface utilisateur.

Citation de l'article lorsqu'on lui a demandé s'il fallait modéliser les pays en tant qu'entités ou objets de valeur:

Il n'y a rien de intrinsèquement mauvais à modéliser les pays en tant qu'entités et à les stocker dans la base de données. Mais dans la plupart des cas, cela complique les choses. Les pays ne changent pas souvent. Lorsque le nom d'un pays change, il s'agit en fait, à toutes fins pratiques, d'un nouveau pays. Si un pays n'existe plus un jour, vous ne pouvez pas simplement changer toutes les adresses, car il est possible que le pays ait été divisé en deux pays.

Il a suggéré une approche différente pour introduire un nouveau concept appelé AvailableCountry:

Ces pays disponibles peuvent être des entités dans une base de données, des enregistrements dans un JSON ou même simplement une liste codée en dur dans votre code. (Cela dépend si l'entreprise souhaite y accéder facilement via une interface utilisateur.)

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

Il semble donc qu'il existe une troisième solution qui consiste à modéliser les tables de recherche en tant qu'objets de valeur et entités.

BTW assurez-vous de vérifier la section des commentaires pour des discussions sérieuses sur l'article.

Choses à considérer:

• Quelle est la statique des données? Si cela ne changera jamais, alors il devrait vivre dans l'objet. Pour modifier les données, vous devrez peut-être recompiler et redéployer. Êtes-vous satisfait de faire un redéploiement pour un changement mineur?

• S'il s'agit d'une application Web et que vous l'avez dans le cadre de web.config, êtes-vous satisfait du redémarrage de l'application lorsque vous apportez des modifications à ces données?

• Si vous le placez dans une base de données, vous pouvez toujours le mettre en cache côté client (application de bureau) ou côté serveur (service ou site Web). La base de données pourrait être une bonne solution OMI.