Question

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

每个文件夹都有一个唯一的固定大小的ID，并且预期的文件夹数量非常高，可以达到数百万，并且系统应该维持这一点而不会出现严重的降级。每个文件夹包含有限数量的任意大小的文件（~10）。虽然很小，但有些可能达到几MB的顺序。

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

现在，我需要设计并实现它。一种非常天真的方法是使用具有平面层次结构的文件系统“逐字地”实现这样的系统。但从长远来看这是不切实际的，因为文件系统目录实际上是一个对象，每当你向目录添加/删除某些东西时都会重写它。因此创建一个子目录而数百万已经存在 - 显然是一个坏主意。

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

但是还有一个选项可以将所有数据存储在数据库中，例如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。）

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

2 个答案: