【问题标题】:Same data for many enitites in database数据库中许多实体的相同数据
【发布时间】:2017-02-26 23:04:50
【问题描述】:

不久前,我实现了一个类似 gdrive/dropbox 的应用程序,它具有全局预定义的目录结构(不可修改),每个用户都可以使用,但不限于(意思是:还能够添加和管理自定义文件夹)。

静态目录结构是这篇文章的原因,因为我对当前的处理机制不满意,如果你能给我一个好的建议,我会如何改进它/改变它变得更好.

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

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

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

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

感谢您的帮助! :-)

【问题讨论】:

  • 多个用户可以使用一个特定的文件夹?
  • 有多少个文件夹?用户?文件? ETC?你在说什么?数百万,或者只有数千。对于数千人,我建议构建一个逻辑结构而不用担心性能。对于数百万人,让我们看看一些实际的模式和查询。 使用任何一种方法,您都可以编写性能不佳的查询。

标签: mysql database-design


【解决方案1】:

如果我理解正确,您将所有文件都存储在数据库中。因此,您可能有一个表 files 包含文件(二进制)及其文件夹 ID。因此,毕竟文件夹只是名称,以使用户能够构建他们的数据并轻松访问。但这也意味着,您不必在必须使用递归查询扫描的数据库中使其成为分层结构。

比如说,A里面有一个固定文件夹A和一个固定文件夹B。用户添加了三个文件夹。这些是folders表中的用户记录:

id 文件夹路径 user_id 1 A 1(每个用户都有这个) 2 A/B 1(每个用户都有这个) 3 A/B/C 1 4 天 1 5日/日 1

如果用户打开他们的存储,则会显示所有主文件夹(folder_path 中没有破折号的文件夹):A 和 D。如果用户打开其中一个文件夹,比如 A,则显示里面的所有文件夹(即所有以A/ 开头并在folder_path 中有一个破折号):在我们的例子中是A/B,加上所有带有folder_id 的文件 1. 如果用户将B 重命名为F,则更改每个folder_pathA/B 开头改为以A/F 开头。如果用户将F 移动到E 内部,则将每个以A/B/F 开头的folder_path 改为以D/E/F 开头。

计数文件同样简单:

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

所有这些都是简单的操作,因为实际上不需要移动任何东西,您总是只会查找路径以某个字符串开头的文件夹,或者您会更改文件夹路径的开头。

【讨论】:

  • 感谢您的回复!对不起,我没有说清楚:是的,有一个文档表,但它不包含文档本身,而是一个路径(与文件夹数据库中的虚拟路径无关)到文件上的文件它引用的文件系统。但这对于您建议的解决方案无关紧要,它仍然适用并且似乎至少解决了文档计数问题。如果这真的解决了所有要求,我需要更彻底地考虑这一点,但目前看来如此。再次感谢! :-)
猜你喜欢
  • 2019-02-14
  • 2018-03-30
  • 1970-01-01
  • 2018-07-18
  • 2019-04-17
  • 1970-01-01
  • 2023-02-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多