公式の sqlite3 Web ページに、fopen() 関数の代わりとして sqlite を考えるべきだと書かれています。
あなたはそれについてどう思いますか?アプリケーションの内部データストレージをsqliteで補充することは常に良い解決策ですか? そのようなソリューションの長所と短所は何ですか?
その経験はありますか?
編集:あなたの経験はどうですか?使いやすいですか?苦しかったか、むしろうれしかったか。あなたはそれが好きですか?
公式の sqlite3 Web ページに、fopen() 関数の代わりとして sqlite を考えるべきだと書かれています。
あなたはそれについてどう思いますか?アプリケーションの内部データストレージをsqliteで補充することは常に良い解決策ですか? そのようなソリューションの長所と短所は何ですか?
その経験はありますか?
編集:あなたの経験はどうですか?使いやすいですか?苦しかったか、むしろうれしかったか。あなたはそれが好きですか?
場合によります。いくつかの禁忌があります:
構成ファイルの場合、プレーン テキストまたは XML を使用すると、SQLite のような軽量のリレーショナル データベースを使用するよりも、デバッグや変更がはるかに簡単になります。
ツリー構造は、リレーショナル テーブルを使用するよりも (たとえば) XML を使用して記述する方が簡単です。
SQLite API の文書化はかなり不十分です。十分な例がなく、ハイパーリンクも貧弱です。OTOH、あなたがそれを掘り下げる気があるなら、情報はすべてそこにあります.
アプリ固有のバイナリ形式を直接使用すると、BLOB と同じ形式をデータベースに格納するよりも高速になります。
データベースの破損は、単一の不良ファイルではなく、すべてのデータの損失を意味する可能性があります
OTOH、あなたの内部データがリレーショナル モデルにうまく適合し、それがたくさんある場合は、SQLite をお勧めします - 私は自分のプロジェクトの 1 つでそれを使用しています。
経験について - 私はそれを使用していますが、うまく機能し、既存のコードと簡単に統合できます。ドキュメントがより簡単にナビゲートできれば、5 つ星を付けますが、現状では 4 つを付けます。
いつものことですが、「フリーサイズ」のソリューションはありません。
スタンドアロン ファイルにデータを格納する必要があり、SQL データベースのリレーショナル データベース機能を利用できる場合は、SQLite が最適です。
データがリレーショナル モデル (階層データなど) に適していない場合、またはデータを人間が読み取れるようにしたい場合 (構成ファイル)、または別のシステムと相互運用する必要がある場合、SQLite はあまり役に立たず、XML はあまり役に立ちません。良くなる。
一方、複数のプログラムまたはコンピューターから同時にデータにアクセスする必要がある場合、SQLite は最適な選択ではなく、「実際の」データベース サーバー (MS SQL、Oracle、MySQL、PosgreSQL ...) が必要です。 .
SQLite の原子性はプラスです。一部のデータを途中で書き込んだ場合 (途中でクラッシュする可能性があります)、データ ファイルが破損しないことを知っています。私は通常、正常にロードされたファイルをバックアップすることで xml 構成ファイルで同様のことを達成し、将来ロードに失敗した場合 (破損を示す) は、最後のバックアップを自動的に復元します。もちろん、粒状でもアトミックでもありませんが、私の欲求には十分です。
私は SQLite を扱うのが楽しいと思いますが、fopen() の万能な代替品とは考えていません。
例として、Web サーバーから画像をダウンロードしてローカルにキャッシュするソフトウェアを作成しました。それらを個別のファイルとして保存すると、Windows エクスプローラーでそれらを見ることができます。これには確かに利点があります。しかし、キャッシュを使用するには、URL と画像ファイルの間をマップするインデックスを保持する必要があります。それらを SQLite データベースに保存すると、それらはすべて 1 つのきちんとした小さなファイルに格納され、URL (url=' http://foo.bar.jpg ' のキャッシュから imgdata を選択) で簡単にアクセスできます。