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

Question

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

每个文件夹都有一个唯一的固定大小的 ID，文件夹的预期数量相当高，可以达到数百万，并且系统应该能够维持这一点而不会出现显着降级。每个文件夹包含有限数量的任意大小的文件(~十个)。大部分很小，但有些可能达到几 MB 的量级。

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

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

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

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

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

因此，我的问题是:与文件系统( 分层的)相比，这听起来像是一个重大缺点吗？

Answer 1

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