2017-02-26 69 views
0

前一段时间,我实现了一个带有全局预定义目录结构(不可修改)的gdrive /类似于dropbox的应用程序,每个用户都可以使用该目录结构,但不限于(意思是:也能够添加和管理自定义文件夹)。数据库中许多相关数据的相同数据

静态目录结构是这篇文章的原因,因为我不满意目前的处理机制,并且会非常高兴,如果你能给我一个很好的建议,我可以改进它/改变这个更好。

目前我使用一个MySQL数据库,其中有一个表'文件夹',这(惊喜,惊喜)包含所有文件夹(预定义和自定义)。因此它具有文件夹名称,所有者和父文件夹的字段。

因为预定义的结构非常庞大,所以我不想为每个用户添加它到表中,因此我只用此结构的一个实例为文件夹表添加并将“owner”字段设置为NULL 。因此,要查找用户的所有文件夹,我只需要查询将此特定用户作为所有者或不属于任何人的那些文件夹。

这种方法目前效果很好,但对于文件夹的每个用户属性有一些主要缺点,例如,我想在每个目录中显示文档计数 - 包括子目录 - 这是每次使用非常慢的递归查询完成的。如果我只有每个用户文件夹结构(例如,通过添加一个额外的“文档计数”字段,可以更好地处理这个问题),每当文件夹中的文档发生某些事情时可以使用查询挂钩来更新该字段结构体)。

您对这个设计选择有什么看法?我是否应该保持这种状态,只需添加一个包含每个用户文件夹属性的附加表(例如像user_id,folder_id,document_count,last_modified,[我可以想到的任何其他属性])?如果直接在系统上处理文件夹(通过使用系统命令)并将它们保存在数据库之外,这会是一种更好的方法吗?或者你有没有其他的想法(或许是更合适的数据库?),这可以用更方便的方式进行管理。

感谢您的帮助! :-)

+0

多个用户可以使用特定的文件夹? –

+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/folder_path有一个破折号):在我们的例子A/B,再加上所有文件folder_id 1.如果用户重命名BF然后更改每folder_path与开始代替A/BA/F开头。如果用户将F移动到E的内部,则每改变folder_path,以A/B/F开始改为以D/E/F开始。

计数文件一样容易:

select count(*) 
from files 
where folder_id in (select id from folders where folder_path like 'A/B%'); 

所有这些都是简单的操作,因为什么事都没有实际移动,你永远只能仰望的文件夹,其中开始具有一定的字符串或你的路径'd改变文件夹路径的开始。

+0

感谢您的回复! 对不起,我没有说清楚:是的,有一个文档表,但它不包含文档本身,而是一个路径(与文件夹数据库中的虚拟路径无关)到文件它所引用的文件系统。但是,对于您的建议解决方案而言,这并不重要,它仍然适用并似乎至少解决了文档计数问题。如果这真的解决了所有的要求,我需要更彻底地考虑这一点,但目前看起来如此。再次感谢! :-) – Tek