database - フォルダ システムを格納するためのデータベース スキーマの選択

Question

複雑なサブ構造を持つ 100GB フォルダーの完全な構造を格納できる SQLite ベースのデータベースを実装しようとしています (50 ～ 100K ファイルが予想されます)。DB の主な目的は、このフォルダーのさまざまな側面 (合計サイズ、フォルダーのサイズ、フォルダーの履歴とそのすべてのコンテンツなど) に関する迅速なクエリを取得することです。

ただし、 parent_directoryフィールドだけで「ファイル」テーブルを作成するだけでは、再帰クエリなしでは、サブフォルダーのすべてを含むフォルダー内のすべてのファイルを見つけることができないことに気付きました。これは、コードに必要な最も重要な機能の 1 つだと考えているため、下の図に示すように、このための 2 つのスキーマ オプションを検討しました。

1. スキーマ 1 では、すべてのファイル名を 1 つのテーブルに格納し、ディレクトリ名を別のテーブルに格納します。どちらにも「parentdir」アイテムがありますが、ルートから特定のファイル/ディレクトリへのパス全体を保存する「FullPath」と呼ばれるテキスト（明らかにテキスト/ブロブはsqliteでは同じです）フィールドもあります（ /etc/ など） abc/def/wow/longpath/test.txt)。最大サブフォルダー制限を想定していないため、理論的には最大 30K 文字を許可するフィールドになる可能性があります。私の考えは、親に属するすべてのファイルまたはディレクトリが必要な場合は、このフィールドで親のフルパスを照会して、ファイルIDを取得するだけです

2. スキーマ 2 では、ファイル名、ファイル ID、DirName、DirID のみをディレクトリとファイル テーブルにそれぞれ格納します。しかし、「Ancestors」と呼ばれる 3 番目のテーブルでは、ファイルごとに、その祖先である各ディレクトリの一連のエントリを保存します (上の例では、test.txt には 5 つのエントリがあり、フォルダの DirID などを指します。 abc、def、wow、および longpath をそれぞれ）。次に、任意のフォルダーの完全なコンテンツが必要な場合は、このテーブルで DirID を探し、すべてのファイル ID を取得します。

スキーマ 1 の主な制限は、可変長テキスト列の全文検索であり、スキーマ 2 の主な制限は、100 ディレクトリなどの奥深くに埋もれているファイルに大量のエントリを追加する必要があることです。 .

これらのソリューションの中で何が最善でしょうか? 私が思いつかなかったより良い解決策はありますか？

Answer 1

1. 最初のスキーマは問題なく機能します。列にインデックスを配置するときは、クエリにFullPath大文字と小文字を区別する演算子を使用するか、インデックスまたは with で with を使用します。BETWEENLIKECOLLATE NOCASEPRAGMA case_sensitive_like

   このスキーマにはすべての親も格納されますが、ID (名前) はすべて 1 つの値に連結されることに注意してください。

   ディレクトリの名前を変更するには、そのすべてのサブツリー エントリを更新する必要がありますが、履歴について言及しているため、古いエントリが同じままである可​​能性があります。

2. 2 番目のスキーマは基本的に、Dan D のコメントで言及されているClosure Tableです。深さ 0 のエントリを忘れないように注意してください。

   これには大量のデータが保存されますが、ID であるため、値が大きすぎないようにする必要があります。

   （実際には必要ありRelationshipIDませんよね？）

3. ツリーを格納するためのもう 1 つの選択肢は、入れ子集合モデル、または同様の入れ子間隔モデルです。ネストされたセット モデルでは、一定間隔でクエリを実行してサブツリーを取得できますが、更新は複雑です。ネストされた間隔モデルは分数を使用しますが、これはネイティブ データ型ではないため、インデックスを作成できません。

最初の選択肢が最も使いやすいと思います。ルックアップが適切にインデックス化されていれば、他の人よりも遅くなることはありません。

Answer 2

私の個人的なお気に入りは訪問数アプローチです。これは、レコードとその子孫に対して集計クエリを実行するのが非常に簡単になるため、特に役立つと思います。