データベースを使用するのが適切かどうかを判断する最良の方法は何ですか？

PHPとMySQLを使用したWeb開発でプログラミングのキャリアを始めました。ほとんどの動的データといくつかの設定/パラメータデータの保存にdbを使用することに慣れました。多くのデータがある場合もあれば、テーブルのエントリが少ない場合もあります。私にはこれは自然なことのように思えましたが、私が知っている限りでは、これは多かれ少なかれWeb開発で受け入れられるアプローチです。（間違っている場合は修正してください...）

私は現在デスクトップアプリケーションを掘り下げており、私の本来の傾向は、dbを再び使用して、アプリケーションの使用を通じて生成される多くの情報を保存することです。 ただし、私が知る限り、dbを頻繁に使用するアプリケーション（使用しているアプリケーション）は表示されません。 [編集：これは、多くのアプリケーションがプログラム自体に埋め込まれた軽量のデータベースを使用するという点で誤った仮定であると指摘されています。] この理由は何ですか？どの時点でdbを使用するのが適切ですか？この問題に関する基準はありますか？また、dbを使用してデスクトップアプリケーションを開発しない理由は何ですか？

アプリケーションがドキュメント指向の場合は、ドキュメントファイルに保存します

アプリケーションが1つのドキュメント（XMLドキュメントなど）に対して多すぎる構造化データを処理する場合は、データベースを使用します

従来、データベースシステムは比較的重いサービスと見なされてきました。必ずしもすべてのクライアントマシンにインストールする必要はありませんでした。実際に、実際のDBシステムが「理想的な」ソリューションである状況（多くのデータを保存する必要があるデスクトップGUIアプリ開発）を経験しました。代わりにフラットデータファイルを使用しました。

最近は軽量なデータベースがいくつかありますが、これはクライアント側のデータベースに対する有効な議論です。数十個の設定とパラメーターを保存する必要のあるシンプルな小さなデスクトップアプリ（シンプルなデスクトップグッズやゲームなど）を想像してください。あなたのアプリを実行するためだけにMySQLをインストールする人を作ることは、何よりも上に思えます。

Web開発では、サーバーは当然のことながらバックエンドであり、データベースを持つことは当然のことです。例えば。ユーザーは、最後にデータベースをインストールすることを心配する必要はありません。

デスクトップアプリケーションは、実行中に状態を維持します。Web開発は通常そうではありません。そのため、ページの読み込みと読み込みの間にデータベースにユーザー設定を保存する必要があるかもしれませんが、デスクトップアプリではメモリに保存するだけです。これにより、このようなタイプの永続ストレージの必要性が大幅に削減されます。使用ごとに設定を保存する場合は、すべてを1つのファイルに保存するか、Windowsレジストリのような場所に配置できます。

とはいえ、データベースシステムはデスクトップアプリで非常に多く使用されています。ウェブよりずっと前から、デスクトップアプリケーションはDBMSに接続されてきました。主にドキュメントベースではないアプリケーション用。最近では、軽量エンジンの可用性が向上しているため、ラインが少しぼやけています。例として、いくつかのアプリでSQLite db をドキュメントとして使用しています。

検討したいことの1つは、実際に実行中のデータベースサービスを必要としない軽量データベースです。たとえば、MicrosoftのフロントにはSQL Server Compactがあります。これは無料で、データベースに1つのファイルとアプリに追加されたいくつかのDLLのみを必要とします。開発者の観点からは、「実際の」SQL Server

他のプラットフォームにも同様のオプションがあると確信しています。

Webアプリケーションでは、永続的な状態を集中ストレージに保存することが重要です。通常、Webアプリは最初のボトルネックであるため、どのコピーにデータが含まれているかを質問することなく、単に配布できることが重要です（「Shared Nothing」の原則）。データベースだけでなくmemcached、キューシステムも同じ理由で存在します。

デスクトップアプリには、同じスケーラビリティの目標はありません。通常、ほとんどのデータは各ワークステーションにローカルに保存されます。ほとんどの場合、データ共有は別の問題です。これにより、データベースを使用する1つの大きな理由がなくなります。

GUIアプリケーションには、メモリ内のオブジェクトの複雑なWebとして処理される可能性のある複雑なドキュメントを含めることもできます。構造をリレーショナルDBスキーマに正規化すると、問題が大幅に複雑になる可能性があります。場合によっては、単一のバイトストリームで全体をシリアル化する方が簡単な場合があります。多くのOOPフレームワークには、そのための機能がいくつか含まれています。

それでも、多くの場合、保存されたドキュメントをメインアプリケーションの外部のツールで読み取り可能にすることは大きな利点です。そのため、人間が読み取れる形式（XML、JSON、YAMLなど）を使用するか、もっと一般的。

同様に、埋め込み可能なデータベースライブラリ（BDB、東京キャビネット、SQLite、MS-SQL * server Compactなど）を使用することも、もう1つの優れたアプローチです。

データベースは過剰になる可能性がありますが、通常はそうする必要はありません。非常に単純なプログラムは、それらを必要としません。文書がささいな時間でメモリに読み込まれ、問題なくそこに留まることができる場合、多くのプログラムで実際に必要になることはありません。

たとえば、次のことを考慮してください。

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

まあ、それは過度に単純化されていますが、明らかにこれは多すぎます。「Hello World」でそのレベルのデータ管理をすることには、本当の意味はありません。

通常、私が経験する経験則では、多くのデータセットがある場合はデータベースを使用します。特にデータセットが一意に異なる場合、またはデータ量がかなり大きい場合はデータベースを使用します。一般にデータベースはいくらかのオーバーヘッドに関連付けられていますが、実際にはそれほど多くのデータベースはありません。たとえば、小型で軽量のインメモリデータベースは、処理、スケジューリング、またはデータの動的な変更が多い小規模なプロジェクトに役立つ場合があります。

さまざまなコーディングスタイルがあり、多くの場合、データベースに問題はありませんが、私たちのほとんどは基本的なタスクに「そこまで」行きません。適切なデータベースがパフォーマンス上の利点を提供する場合もあります。データがどこにあるのか、どのくらいの期間存在するのか、そしてそのデータが存続期間中に何を変更するのかという違いを特に理解するようにしてください。

dbを使用することは常に正しいことであり、SQLiteの実装では、実際にすべての言語に使用するのではなく、dbを使用すると、設計上の意思決定が不十分になります。使用しない唯一の理由は、組み込みプログラミングまたは他の種類の非アプリケーション形式のプログラミングを実行している場合です。SQLなどの宣言型言語を使用してデータと設定を照会する方が、命令型構文でメモリ内のフラットファイルやその他のオブジェクトを走査するよりもはるかに自然です。さらに、データ操作を他のアプリケーションコードから明確に分離するため、長期的にはコードがよりモジュール化され、保守しやすくなります。