Question

目前我正在寻找一个可嵌入的数据库（C ++，Win32），我发现SQLite很有魅力。但是，我想知道在SQL数据库中存储文件路径和文件属性是否有意义。在服务器系统上，文件的数量可以从几百或几千到几百万或几十亿。这是一个探索磁盘内容的软件（不过是文件本身的内容）。

我在想的是一个用于存储完整目录部分的表，另一个用于存储文件属性（包括名称）。然后，后者将包含对“父”文件夹的反向引用。

我正在考虑的一件事是目录表是否应存储每个目录的完整路径，这将导致存储冗余信息，例如：

ID | Name
0  | C:
1  | C:\Windows
2  | C:\Windows\System32
3  | C:\Windows\System32\config

而不是：

ID | Name     | Parent
0  | C:       | NULL
1  | Windows  | 0
2  | System32 | 1
3  | config   | 2

当然，除了存在某种修剪或引用计数之外，我不能对保存存储/内存以及存储每个字符串的单个实例（每个路径组件）感到“贪婪”......

您认为哪一个优越，为什么？第二种方法不会造成性能损失吗？

此外，是否有任何项目FLOSS并实现了类似的东西（存储分层路径名和属性），最好已经与SQLite一起使用了？

在我想到的架构中，文件C:\Windows\System32\config\SOFTWARE将由以下内容表示：

ID | Name   | Folder | Size    | Attributes | ...
42 | SYSTEM | 3      | 1024000 | 0x00000301 | ...

Answer 1

SQLite应该能够轻松处理这个问题。请参阅Appropriate Uses For SQLite。

我更喜欢你桌子的第二种自我加入的形式。 SQLite应该在Parent字段中包含的ID回到ID（应该有索引）之后出现问题。但Name字段也应该有一个索引。这样，当您在表中插入新条目时，可以快速查找现有文件夹。