SQLiteデータベースまたは個別にテーブルに設定を保存しますか？
SQLiteを使用するアプリケーションを構築していて、セッション間で保存される設定を追加したい
configファイルに設定を保存するか、またはを使用するか検討しています=）データベースのテーブルこのため
（データをローカルに保存し、ユーザーアカウントを持たないSQLiteを使用していることに注意してください）
データベースの使用を考えているのは、複雑さを増やさないようにしたいからです。すでにSQLiteデータベースをセットアップしているので、同様に設定にも使用します
これら2つのオプションから選択する場合、何を考慮する必要がありますか？
私はデータベースのテーブルを使用することに傾いていますが、 この答え はデータベース内に設定を保存することは懸念の分離が悪いと言っているので少し心配です。
ただし、実際にどのような欠点があるのかはわかりません。自己文書化するコードと読みやすさの観点から、dbテーブルが単に「設定」と呼ばれる場合、設定がどこにあるかは明らかです。
（私が考えることができる1つの欠点は、設定がdbスキーマよりもはるかに速く変更されることを期待する場合かもしれません、それは設定を変更するよりも複雑なデータベースの変更を意味するためです）
これで助けてくれてありがとう！
同様の質問：
- ビジネスルールの保存に構成ファイルまたはデータベースを使用する必要がありますか？ ---私の質問に似ていますが、より具体的です（ビジネスルールの保存について）。さまざまなオプションを選択する際の一般的な考慮事項について知りたい
- 一般的な設定はプログラムにどのように保存されますか？
私が保守している大規模なレガシーアプリケーションは、何年にもわたってこれを行ったり来たりしていますが、ほとんどの設定をDBに保持するように進化しています。はい、DB接続文字列は設定ファイルから読み取られます。これは、DBを頻繁に使用するデスクトップアプリケーションであり、かなりの数の設定があります。数が非常に少ない場合、これはあまり当てはまりませんが、これらが頭に浮かぶ最初の理由です。
構成ファイルは通常、起動時にのみ読み取り、変更はアプリケーションの再起動を意味します。 （厳密な規則ではありませんが、使用目的です。）
DBからの設定は、アプリケーションの一部であるGUIを介して編集でき、外部ファイルにアクセスする必要なく、既存のDBルーチンを使用して直接更新できます。
GUIによって行われた変更は、イベントを発生させるために簡単に使用でき、新しい値をすぐに使用できます。外部ファイルへの変更を監視したくない場合は、最初の箇条書きを参照してください。
通常のユーザーはDBにアクセスできず、そこでの変更を制限および検証できます。構成ファイルが公開されており、値の検証なしで任意のエディターで変更できます。
インストールごとにカスタマイズされる一連の設定（「プロファイル」）があります。これは、設定ファイルで維持するのがやや面倒です。
設定をデータベーステーブルに保存することは、懸念の分離に悪いことだと私は同意しません。 「懸念」は、データベース内の設定テーブルと他のテーブルとの関係を定義しないことによって分離されます。これで結構です。
考慮すべき主なことは、システムの管理者が設定を変更することをどのように期待するかです。ほとんどの人にとって、構成ファイルを開いて変更を加える方がはるかに簡単です。設定をデータベースに保存する場合、ユーザー/管理者に変更を加えるためのアクセス権を与える必要があります。データベースに直接変更を加えることに抵抗がある場合は、それらの変更を行うためにアプリケーションに画面を提供する必要がある場合があります。私はこれをWebアプリケーションとモバイルアプリケーションの両方で実行しましたが、正常に動作します。 （変更はアプリケーション自体を介して行われるため、ファイルを編集して外部から変更を行った場合と同様に、アプリケーションを再起動する必要もありません。）
それはすべて、設定の大きさに依存します。値が2つあれば、ファイルに保存する方が簡単でオーバーヘッドも少なくなります。特に、このファイルは扱いやすいXMLである可能性があります。
安全な場所に設定を保存する必要がある場合（資格情報を保存する場合など）は、データベースの方が少し優れています。もちろん、それらをファイルまたはテーブルに保存するときに、これらの資格情報を暗号化する必要があります。
アーキテクチャの観点からは、少なくとも1つの情報、つまりデータベース接続文字列をファイルに保存して、ハードコーディングしないようにする必要があります（悪い習慣）。