静的データをデータベースまたは他の場所に保存する必要がありますか？

現時点ではいくつかのソフトウェアに取り組んでいますが、これでどのルートを取るべきかわかりません。モバイルデバイスのどこかに保存するデータがあります。データは決して変化せず、階層的な関係があり、表示の入力に使用されます。このデータにはかなりの量があります。

次のオプションがあります。

1. 列挙型/オブジェクトのセット
2. XMLファイル
3. 組み込みSQLiteデータベース

この特定のケースでは、enumsオプションが最も作業が少ないと思いますが、そのようなコードに埋め込まれているデータから匂いがします。

XMLファイルは最も理にかなっていると思いますが、それを解析することはリソースヒットになります。

データベースのパフォーマンスへの影響はそれほど大きくありませんが、静的データでは過剰すぎるようです。

ここで正しい設計パスはどれですか？

注：「決して」変更しないと、変更されることはほとんどありません。問題のデータは一連の政府標準のモデルであるため、将来のある時点で変更される可能性がありますが、定期的に変更されることはなく、標準の変更によってソフトウェアが自動的に更新されることもありません要件の変更をトリガーします。

これにはオブジェクトを使用します。

データは決して変更されないので、アプリケーションに簡単に保存できます。データベースが過剰になり、サイズが大きくなります。
XMLファイルもちょっとやりすぎで、サイズも大きくなります。

したがって、私の意見では、最良のオプションは列挙型またはオブジェクトです。

それは決して変わらないのか、それとも変わるのか それはあなたが本当に良い回答を得る前に答えなければならない質問です。

変更されない静的データ（曜日名など）は、コードに含めると便利です。

実際には変更されないデータ（たとえば、サーバーのDNS名）も変更する必要がある場合はコードに含めるとよいので、コードの更新が問題ないほどまれです。

変更されないが、定期的な更新間の時間遅延などのデータは、おそらくローカル構成ストア（sqliteまたはxml、実際の違いはありません）などの簡単に変更できる場所で最適です。

ストレージはほとんど問題になりません-変更されないか、ほとんど変更されない場合は、プログラムの起動時にすべて読み込み、プログラムデータとしてキャッシュできます。万が一、変更が必要になった場合、アプリの再起動はそれほど重要ではありません。

通常、「決して変更しない」ことが最初に変更されます...
必要に応じて簡単かつ迅速にアクセスできる限り、データベースを使用するか他の外部システム（構成ファイルなど）を使用するかは重要ではありません。
とにかく既にデータベースを持っている場合はデータベーステーブルを使用する傾向があり、それは理にかなっています（たとえば、アプリケーションが展開されているサーバーへのファイルシステムアクセス権がないか、複数のマシンで実行されるユーザーがデータを変更する必要がある場合など）また、構成を同期させる必要があります）。
もちろん、データベースはすべてを保持することはできません。たとえば、データベースの資格情報は、他の場所（ほとんどの場合、構成ファイル）に保存する必要があります。

データを要求する問題は、データが変化するかどうかではありません。おそらくあなたは知らないでしょうし、たとえ知っていたとしても、答えはおそらく誤解を招くでしょう。

尋ねるべき質問は、変更された場合、誰が変更すべきかということです。

• ソフトウェアの作成者：コードに入れる
• エンドユーザー：GUIにオプションがあります
• 他の誰か（たとえば、システムインテグレーター、国際化サービスなど）：データベーステーブル、ファイル、または意味のあるもの（場合によっては拡張APIを含む）。

火曜日は一般的に列挙型である必要があります。決して変更できないからです。しかし、非常識な独裁者が火曜日に彼にちなんで名前を付けることを要求した場合、ソフトウェア作成者としてあなたはそれを変更する必要があります（またはサメに与えられます）。

その運命を避けるために、すべてのユーザーが設定ファイルを掘り下げたり、データベーステーブルを不明瞭にする必要はありません...

データが実世界で表すエンティティがそうでなくても、「あなたの」データを変更する必要があるかもしれません。アプリ全体を更新せずに更新できる、ある種の別のテキストファイルを含めることが価値があるかどうかを判断する必要があります。

例：

1. 誤字/スペルミス。
2. 偶然の省略。
3. 別の言語でデータを提供します。
4. ユーザーが独自の変更を行う方法を提供します。

他のタイプのデータ構造の変更には、おそらくアプリの更新が必要になるため、メリットはありません。

私は元々、この質問に対するこの回答をstackoverflowで書きましたが、この質問にも同じ答えが当てはまると思います。

Mathias Verraesによるあなたの問題についての記事がここにあります。彼は、UIに役立つ概念からモデル内の値オブジェクトを分離することについて話しています。

国をエンティティまたは値オブジェクトとしてモデル化するかどうかを尋ねられたときの記事からの引用：

国をエンティティとしてモデリングし、それらをデータベースに保存しても本質的に問題はありません。しかし、ほとんどの場合、それは複雑すぎます。国はあまり変わりません。国の名前が変わると、実際には、すべての実用的な目的のために、新しい国になります。ある国がもう存在しない場合、その国は2つの国に分割されている可能性があるため、単にすべての住所を変更することはできません。

彼は、次のような新しい概念を導入するための別のアプローチを提案しましたAvailableCountry。

これらの利用可能な国は、データベース内のエンティティ、JSON内のレコード、または単にコード内のハードコーディングされたリストです。（これは、ビジネスがUIを介して簡単にアクセスしたいかどうかによって異なります。）

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

したがって、ルックアップテーブルを値オブジェクトとエンティティの両方としてモデル化する3番目の解決策があるようです。

ところで、この記事に関するいくつかの深刻な議論については、コメントセクションを確認してください。

考慮事項：

• データはどの程度静的ですか？変更されない場合は、オブジェクト内に存在する必要があります。データを変更するには、再コンパイルと再デプロイが必要になる場合があります。小規模な変更のために再デプロイを行って満足していますか？

• Webアプリケーションであり、web.configの一部として使用している場合、そのデータに変更を加えたときにアプリケーションを再起動しても問題ありませんか？

• データベースに配置すると、クライアント側（デスクトップアプリケーション）またはサーバー側（サービスまたはWebサイト）でいつでもキャッシュできます。データベースはIMOに適したソリューションかもしれません。