存储文件夹系统的数据库模式的选择

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的方法，我认为这对你特别有用，因为它使得对记录及其后代运行聚合查询变得非常简单。