SQLite 模拟一个广泛的文件系统结构？

Question

我需要实现一种本地持久存储系统（简单地说——在磁盘上）。应该有（虚拟的）文件夹和文件。

每个文件夹都有一个唯一的固定大小的 ID，并且预期的文件夹数量非常多，可以达到 数百万，并且系统应该能够在不显着退化的情况下维持这一点。每个文件夹包含有限数量的任意大小的文件（〜十个）。大部分都很小，但有些可能达到几 MB。

还值得补充的是，该系统将主要使用最近的文件夹。旧文件夹中需要的概率较低。

现在，我需要设计和实现它。一种非常幼稚的方法是“从字面上”实现这样的系统，使用具有平面层次结构的文件系统。但从长远来看这是不切实际的，因为文件系统目录实际上是一个对象，每当您在目录中添加/删除某些内容时，它都会被重写。因此，在数以百万计的已经存在的情况下创建一个子目录显然是个坏主意。

更好的解决方案是将所有文件夹排列在某种层次结构中（例如基数样式，其中目录名称的前几位定义第一个子文件夹，接下来的几位定义下一个子文件夹，依此类推。

但还有一个选项可以将所有数据存储在数据库中，例如 SQLite（我过去有过很好的经验）。有了适当的索引，它应该比文件系统更快（即寻找特定的文件/子文件夹）。而且我也喜欢在事务模式下修改的能力（虽然我也可以没有这个）。

到目前为止，DB 选项看起来更胜一筹。但它似乎也有一个缺点。这与关系数据库结构是flat这一事实有关。意味着，当我需要访问特定对象（文件）时 - 基本上搜索整个数据库。我无法隔离某些特定的子文件夹。例如，访问同一目录中的多个文件将不可避免地导致针对每个此类文件搜索所有此类文件（假设它们有一个单独的表），尽管它们都“存在”在同一目录中。

所以，我的问题是：与文件系统（是分层）相比，这听起来像是一个重大缺点吗？

Answer 1

不，我不这么认为。我认为数据库会更快更容易实现和维护。

Answer 2

你说：

有了适当的索引，它应该比文件系统更快

和：

当我需要访问特定对象（文件）时 - 基本上会搜索整个数据库。我无法隔离某些特定的子文件夹。

这些陈述相互矛盾。有了适当的索引，所有的查询都是高效的。

例如：

CREATE TABLE FileSystem (
    ID        INTEGER PRIMARY KEY,
    ParentDir INTEGER REFERENCES FileSystem(ID),
    Name      TEXT,
    Data      BLOB  -- NULL for directories
);
CREATE INDEX DirNameLookup ON FileSystem(ParentDir, Name);

读取一个名为a/b/c的文件使用这些查询，所有这些查询都可以通过DirNameLookup索引：

SELECT ID   FROM FileSystem WHERE ParentDir IS NULL AND Name = 'a';
SELECT ID   FROM FileSystem WHERE ParentDir = ?     AND Name = 'b';
SELECT Data FROM FileSystem WHERE ParentDir = ?     AND Name = 'c';

（除了使用 IS NULL 作为根目录，您还可以创建一个具有已知 ID 的行，例如 0 或 1。）