3

私のシナリオは状況に依存します。私は、iTunes、Windows Media Player、および Winamp に似た音楽ライブラリ オーガナイザー/プレーヤーを作成しています。すでに ID3 タグ コードはすべて機能しており、データベースの準備が整いました。私の発見では、ロード時に各曲の ID3 タグから直接読み取るよりも、データベースを読み取り、ファイルの MD5 ハッシュをチェックして保存されているものと比較し、曲が変更された場合はデータベースを更新する方がはるかに高速です。 . そうは言っても、私はsqliteデータベースを立ち上げて実行しています。

アルバム アートをデータベースに保存するか、ファイル システムに保存するかがわかりません。アルバム アートのサイズを 300x300 ピクセルに自動的に変更するコードがあるので、すべての写真のファイル サイズは通常、約 15 ～ 30 KB です。これは、通常のサイズの画像と 14.8 MB のサイズの画像に当てはまります。したがって、平均して 22.5 KB のサイズの写真を保存する必要があります。

これは状況に応じた部分です。20,000 曲だけでなく 100 曲の音楽ライブラリを効率的に使用するための決定が必要です。すべての曲にアルバム アートがあると仮定すると、読み込み時間を短縮するためにサブディレクトリを使用する sqlite データベースまたは NTFS ファイル システムのいずれかが適しています。

4

2 に答える 2

0

一般に、データベースは BLOB の格納にはあまり適していませんが、すでに BLOB のサイズを大幅に縮小しているため、問題は少なくなります。

また、いくつかの曲が同じ BLOB を共有している可能性が高いため、曲ごとに BLOB を保存すると、スペースが完全に無駄になる可能性があることに注意してください。

画像のサイズが小さいため、それらをデータベースに保存し、スキーマを調整して、同じ画像を含む複数のブロブを保存しないようにします。これにより、データの一部が 1 つの場所 (データベース) に存在せず、ユーザーが誤って削除してしまう可能性があるファイル システム上の他のデータが存在しないため、データの一貫性を確保することがはるかに簡単になります。

かなり大きなブロブについて話している場合は、おそらくデータベースではなくディスクに保存する必要があります。

于 2012-10-22T19:36:12.227 に答える
0

他の曲データを含む同じテーブルに画像を配置する場合、曲データに対するすべてのクエリで、ディスクからいくつかの画像データも読み込む必要があります。

メインの曲のテーブルと 1 対 1 の関係を持つ別のテーブルにイメージを配置すると、この影響を回避できます。ATTACHそのテーブルをメインデータベースとは別のデータベースに配置すると、画像データをさらに分離できます。これにより、キャッシュを別の方法で構成することもできます。これにより、ディスクに保存されている画像と速度の違いはありません。

定期的に画像をファイルにエクスポートする必要がある場合 (外部プログラムで編集または表示するため)、最初に画像をファイル システムに保存する方が簡単な場合があります。
さらに、イメージをファイルとして保持すると、増分バックアップが容易になります (懸念がある場合)。

于 2012-10-22T19:38:41.117 に答える