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

Question

我正在尝试实现一个基于SQLite的数据库，该数据库可以存储具有复杂子结构的100GB文件夹的完整结构（期望50-100K文件）。数据库的主要目的是快速查询此文件夹的各个方面（总大小，任何文件夹的大小，文件夹的历史记录及其所有内容等）。

然而，我意识到，如果我只使用parent_directory字段创建一个“文件”表，那么在没有递归查询的情况下，找不到文件夹内的所有文件，包括所有文件的子文件夹是不可能的。我认为这是我想要的最重要的功能之一，所以我考虑了两个模式选项，如下图所示。

1. 在架构1中，我将所有文件名存储在一个表中，将目录名存储在另一个表中。它们都有一个“parentdir”项，但也有一个文本（显然是文本/ blob在sqlite中是相同的）称为“FullPath”，它将保存从根到特定文件/目录的整个路径（如/ etc / ABC / DEF /哇/ longpath / test.txt的）。我没有假设最大子文件夹限制，所以这可能理论上是一个允许最多30K字符的字段。我的想法是，如果我想要所有属于任何父级的文件或目录，我只是查询该字段上父级的完整路径并获取fileID

2. 在架构2中，我分别仅在目录和文件表中存储文件名，文件ID和DirNames，DirID。但是在名为“Ancestors”的第三个表中，我为每个文件存储了一组条目，这些条目是它的祖先（因此在上面的示例中，test.txt将有5个条目，指向文件夹的DirID等，分别是abc，def，wow和longpath）。然后，如果我想要任何文件夹的全部内容，我只需在此表中查找DirID并获取所有文件ID。

我可以看到，在模式1中，主要限制可能是对可变长度文本列的全文搜索，而在模式2中，主要限制是我可能需要为深埋在100以内的文件添加大量条目目录或东西。

这些解决方案中最好的是什么？有没有更好的解决方案我没有想到？

Answer 1

1. 您的第一个架构可以正常运行。 当您在FullPath列上添加索引时，请使用区分大小写的BETWEEN运算符进行查询，或者在{1}}上使用COLLATE NOCASE或使用{PRAGMA case_sensitive_like 3}}

   请注意，此架构也存储所有父项，但ID（名称）都连接成一个值。

   重命名目录需要更新其所有子树条目，但是你提到历史记录，所以旧条目可能保持不变。

2. 您的第二个架构基本上是Dan D评论中提到的Closure Table。 注意不要忘记深度为0的条目。

   此将存储大量数据，但作为ID，值不应太大。

   （您实际上并不需要LIKE，是吗？）

3. 存储树的另一种选择是nested set model或类似的嵌套间隔模型。 嵌套集模型允许通过查询间隔来检索子树，但更新是多毛的。 嵌套间隔模型使用的分数不是本机数据类型，因此无法编入索引。

我估计第一种选择最容易使用。 如果正确索引查找，我也应该比其他人慢。

Answer 2

我个人最喜欢的是visitation number方法，我认为这对你特别有用，因为它可以很容易地对记录及其后代运行聚合查询。