存储文件夹系统的数据库模式的选择
use*_*916 25 database sqlite schema database-design
我正在尝试实现一个基于SQLite的数据库,它可以存储具有复杂子结构的100GB文件夹的完整结构(期望50-100K文件).数据库的主要目的是快速查询此文件夹的各个方面(总大小,任何文件夹的大小,文件夹的历史记录及其所有内容等).
但是,我意识到,找到所有的文件夹里面的文件,包括它的所有子文件夹也不是没有可能递归查询,如果我只是做一个"文件"表只是一个parent_directory场.我认为这是我想要的最重要的功能之一,所以我考虑了两个模式选项,如下图所示.
在模式1中,我将所有文件名存储在一个表中,将目录名存储在另一个表中.它们都有一个"parentdir"项,但也有一个文本(显然是文本/ blob在sqlite中是相同的)称为"FullPath",它将保存从根到特定文件/目录的整个路径(如/ etc/ABC/DEF /哇/ longpath/test.txt的).我没有假设一个最大子文件夹限制,所以这理论上可以是一个允许最多30K字符的字段.我的想法是,如果我想要所有属于任何父级的文件或目录,我只是查询该字段上父级的完整路径并获取fileIDs
在模式2中,我分别仅在目录和文件表中存储文件名,文件ID和DirNames,DirID.但是在名为"Ancestors"的第三个表中,我为每个文件存储了一组条目,这些条目是它的祖先(因此在上面的例子中,test.txt将有5个条目,指向文件夹的DirID等,分别是abc,def,wow和longpath).然后,如果我想要任何文件夹的完整内容,我只需在此表中查找DirID并获取所有文件ID.
我可以看到,在模式1中,主要限制可能是对可变长度文本列的全文搜索,而在模式2中,主要限制是我可能必须为深埋在100个目录或其他内容中的文件添加大量条目.
这些解决方案中最好的是什么？有没有更好的解决方案我没有想到？
CL.*_*CL. 20
您的第一个架构将正常工作.当你把一个索引的
FullPath列,使用大小写敏感的BETWEEN运营商进行查询,或者使用LIKE与任一COLLATE NOCASE该指数或PRAGMA case_sensitive_like.请注意,此架构还存储所有父项,但ID(名称)都连接成一个值.
重命名目录需要更新其所有子树条目,但是您提到历史记录,因此旧条目可能保持不变.
你的第二个架构基本上是Dan D评论中提到的关闭表.注意不要忘记深度为0的条目.
这将存储大量数据,但作为ID,值不应太大.
(你真的不需要
RelationshipID,是吗？)存储树的另一种选择是嵌套集模型或类似的嵌套间隔模型.嵌套集模型允许通过查询间隔来检索子树,但更新是多毛的.嵌套间隔模型使用分数,这些分数不是本机数据类型,因此无法编制索引.
我估计第一种选择最容易使用.如果正确索引查找,我也应该比其他人慢.