存儲文件夾系統的數據庫模式的選擇

Question

我想實現一個基於SQLite的數據庫，可以存儲100GB文件夾的複雜子結構（期望50-100K文件）的完整結構。數據庫的主要目的是快速查詢此文件夾的各個方面（總大小，任何文件夾的大小，文件夾的歷史記錄及其所有內容等）。

但是，我意識到，要找到所有文件的文件夾裏面，包括它的所有子文件夾也不是沒有可能遞歸查詢，如果我只是做一個「文件」表只是一個parent_directory場。我認爲這是我想要的代碼中最重要的功能之一，因此我已經考慮了兩個模式選項，如下圖所示。

1. 在模式1中，我將所有文件名存儲在一個表中，並將目錄名存儲在另一個表中。他們都有一個「parentdir」項目，但也有一個文本（顯然文本/ blob是相同的sqlite）字段稱爲「FullPath」，將保存從根目錄到特定文件/目錄的整個路徑（如/ etc/ABC/DEF /哇/ longpath/test.txt的）。我不假設最大的子文件夾限制，所以這理論上可以是允許多達30K個字符的字段。我的想法是，如果我想要屬於任何父級的所有文件或目錄，我只需查詢此字段上父級的完整路徑，並獲取文件標識

2. 在模式2中，我只存儲文件名，文件標識和DirNames，分別在目錄和文件表中的DirID。但是在名爲「Ancestors」的第三個表中，我爲每個文件存儲了每個目錄的一組條目，這是它的祖先（所以在上面的例子中，test.txt將有5個條目，指向文件夾的DirID等， abc，def，wow和longpath）。然後，如果我想要任何文件夾的全部內容，我只需在此表中查找DirID並獲取所有文件標識。

我可以看到，在方案1中的主要限制可能是全文檢索可變長度的文本列模式2的主要限制是，我可能要增加大量的條目對於那些文件，並在深埋在100個目錄之內。

什麼是最好的這些解決方案？有沒有更好的解決方案，我沒有想到？

Answer 1

1. 你的第一個模式會工作得很好。 當您在FullPath列中添加索引時，請使用區分大小寫的BETWEEN運算符進行查詢，或將LIKE與索引上的COLLATE NOCASE或PRAGMA case_sensitive_like一起使用。

   請注意，此模式也存儲所有父母，但ID（名稱）都連接到一個值。

   重命名目錄需要更新其所有子樹條目，但是您提到了歷史記錄，因此可能舊條目應保持不變。

2. 你的第二個模式本質上是丹D的評論中提到的Closure Table。 注意不要忘記深度爲0的條目。

   這將存儲大量的數據，但作爲ID，值不應該太大。

   （你實際上並不需要RelationshipID，你呢？）

3. 存儲樹木另一個選擇是nested set model，或類似區間套模型。 嵌套集模型允許通過查詢間隔來檢索子樹，但更新是多毛的。 嵌套間隔模型使用分數，這些分數不是本機數據類型，因此無法編制索引。

我估計第一個選擇是最容易使用的。 如果查找索引正確，我也不應該比別人慢。

Answer 2

我個人最喜歡的是visitation number的方法，我認爲這對你特別有用，因爲它使得對記錄及其後代運行聚合查詢變得非常簡單。