前一段时间我实现了一个类似gdrive / Dropbox的应用程序,它具有全局预定义的目录结构(不可修改),每个用户都可以使用,但不限于(意思是:还能够添加和管理自定义文件夹)。
静态目录结构是这篇文章的原因,因为我对当前的处理机制不满意并且会非常高兴,如果你能给我一个很好的建议我怎样才能改进它/改进这个更好
目前我使用的MySQL数据库有一个表'文件夹',(惊喜,惊喜)包含所有文件夹(预定义和自定义)。因此,它具有文件夹名称,所有者和父文件夹的字段。
因为预定义的结构非常庞大,所以我不想将每个用户添加到表中,因此我只在文件夹表中添加了一个此结构的实例,并将“owner”字段设置为NULL。因此,要查找用户的所有文件夹,我只需要查询具有此特定用户作为所有者的文件夹,或者不归任何人所有。
到目前为止,这种方法效果很好,但在涉及文件夹的每用户属性时有一些主要缺点,例如:我想在每个目录中显示文档计数 - 包括子目录 - 这是通过每次使用非常慢的递归查询来完成的。如果我只有一个每用户文件夹结构(例如通过添加一个额外的'文档计数'字段,可以更好地处理这个问题,每次在文件夹中的文档发生某些事情时都可以使用查询挂钩更新结构体)。
您对此设计选择有何看法?我应该保持这种方式,只需添加一个包含每用户文件夹属性的附加表(例如,结构如user_id,folder_id,document_count,last_modified,[我能提出的任何其他属性])?是直接在系统上处理文件夹(通过利用系统命令)并将它们保留在数据库之外的更好的方法吗?或者您是否有任何其他想法(可能是更适合的数据库?)如何以更方便的方式管理它。
感谢您的帮助! : - )
答案 0 :(得分:1)
如果我理解正确,您将所有文件存储在数据库中。所以你可能有一个包含文件(二进制)的表files
及其文件夹ID。因此,在所有文件夹只是名称后,用户可以构建数据并轻松访问。但这也意味着,您不必在数据库中将其作为分层结构,您必须使用递归查询进行扫描。
说,A内有固定文件夹A和固定文件夹B.用户添加了三个文件夹。这些是folders
表中的用户记录:
id folder_path user_id 1 A 1 (every user has this) 2 A/B 1 (every user has this) 3 A/B/C 1 4 D 1 5 D/E 1
如果用户打开他们的存储空间,则会显示所有主文件夹(folder_path
中没有短划线的文件夹):A和D.如果用户打开其中一个文件夹,例如A,则显示所有文件夹内(即所有内容均以A/
开头并且在folder_path
中有一个短划线):A/B
在我们的情况下,加上folder_id
的所有文件1.如果用户重命名{{1} } B
然后将以F
开头的每个folder_path
更改为以A/B
开头。如果用户将A/F
移至F
内,则将以E
开头的每个folder_path
更改为以A/B/F
开头。
计算文件同样简单:
D/E/F
所有这些都是简单的操作,因为实际上没有什么必须移动,你总是只查找路径以某个字符串开头的文件夹,或者你改变文件夹路径的开头。