数据库模式：如何设计用户、文件和文件夹之间的关系？答案

【问题标题】：Database Schema: How the relationship can be designed between user, file and folder?数据库模式：如何设计用户、文件和文件夹之间的关系？
【发布时间】：2012-03-16 11:38:42
【问题描述】：

我想知道如何设计 Dropbox 的数据库架构？我正在考虑三个表：具有以下约束的用户、文件、文件夹。

约束：

一个用户可以包含多个文件和文件夹。
每个文件都可以在多个用户之间共享。
一个文件可以为一个用户组织在文件夹中，但不能为另一个用户组织（如果文件是共享的）。
每个文件夹可以包含多个文件以及其他文件夹。

您将如何在它们之间建立关系？

【问题讨论】：

1) 创建一个包含 user_id、file_id、folder_id 作为 fk 的联结表。 file_id 和 folder_id 可以为空。这样我们就可以找到用户的所有文件以及它们是否包含在任何文件夹中。还可以找到给定文件夹（用户的）的所有文件。
2) 由于文件夹与自身是一对多的关系，我们可以创建文件夹表，其中包含一个folder_id列，该列将是一个代表其父文件夹的pk的fk。

标签： database database-design database-schema

【解决方案1】：

Joel Brown's model 是一个好的开始，但让我用另一种可能性来激发你的想象力：

此模型具有以下属性：

它模拟文件系统硬链接。您可以在多个文件夹中拥有一个文件，甚至可以在同一个文件夹中使用不同的名称多次。文件夹也是如此。
它将命名与内容分开，这是“硬链接”范例所必需的。因此，名称位于 FILE_IN_FOLDER 和 FOLDER_IN_FOLDER（而不是 FILE 和 FOLDER）中。
它正确地强制了“本地”名称的唯一性（您不能在同一个父文件夹下有两个以相同方式命名的文件或文件夹）。
用户既不拥有文件也不拥有文件夹。用户只拥有链接。这样，每个用户都有她自己的私有“目录树”，可能会共享所有文件，或者不共享文件或两者之间的任何文件。

当然，问题是您使用此模型获得的灵活性增加是否值得额外的复杂性，但这只有您可以回答...

【讨论】：

感谢您的想法。我在 MSSQL Server 中尝试了这个模式的基本实现。老实说，了解您的设计以及它如何符合所有约束条件是非常有启发性的。但是有一个疑问：“用户既不拥有文件也不拥有文件夹。”如果我们想知道文件的所有者是谁呢？考虑到我们可以允许其他共享用户使用一些访问规则。如何区分用户和其他共享用户？我的想法是在文件（以及文件夹）表中创建一个 owner_id 作为 fk，它在文件和用户之间创建一对多的关系。
@Agent47DarkSoul 是的，您当然可以在 FILE 和 USER 之间创建一个 FK，以将其中一个用户标记为“特殊”（即文件所有者）。问题是，你真的需要这个吗？ IE。是否应该平等对待共享同一文件的所有用户？同样，只有你能回答这个问题......
感谢您清理它。我认为它几乎完成了约束。这听起来可能是个奇怪的要求，但您能帮我了解 Joel 的设计以及它与您的设计有何不同。对此也有一些疑问。你能帮我清理一下吗？再次感谢大家的学习体验。
我也使用这个模式，我有一个问题：考虑以下结构：文件夹 > 子文件夹 > 子子文件夹。因此，当我想与另一个用户共享整个文件夹时，我必须复制所有 3 个“Folder_in_Folder”行并将它们分配给另一个用户对吗？
@Manu 是的，在此架构中，用户必须明确拥有所需的（子）链接集，每个链接由单独的行表示。

【解决方案2】：

此 ERD 符合您描述的规则：

请注意，在此架构中，每个用户都有自己个性化的文件夹视图。另一方面，文件只表示一次，但可以分配给一个或多个文件夹，即使是不同的用户。

编辑：（略微）扩展模型：

通过添加单个表来跟踪物理文件夹及其内容，我提议的架构还解决了 Branko Dimitrijevic 建议的所有附加功能：

【讨论】：

感谢您的意见。对不起，但似乎有一个疑问，我无法摆脱我的头脑。如果文件不存在于任何文件夹中而是直接位于根级别怎么办。那么我们如何才能了解文件存在于哪个用户呢？如果我可能遗漏了什么，我提前道歉。如果您能详细说明图表，将不胜感激。
对架构还有一些疑问：1）为什么我们需要物理文件夹的自1-M关系，因为可以使用虚拟文件夹导出相同的关系（我的意思是重点连接表）？ 2) 为什么物理文件和物理文件夹之间需要1-M的关系？
@Agent47DarkSoul 第一个设计既漂亮又简单，实际上可能正是您所需要的。本质上，每个用户都有自己的私有文件夹树，但文件可以由多个文件夹（因此多个用户）共享。
@Agent47DarkSoul 另外（关于第一个设计），考虑反转 FOLDER 和 USER 之间连接的“方向”，以避免在同一文件夹树中“混合”不同的用户。这样，只有一个（“根”）文件夹将连接到用户，所有权将通过递归查找根文件夹来确定。最初的设计并没有错，我们只是在谈论不同的权衡：易于查询与易于更新和节省存储空间。坦率地说，我可能会使用原始设计，但有一个 CHECK 约束以确保没有用户混合。
@Agent47DarkSoul 至于第二个设计，我不太确定我是否理解它；）它似乎有点过于“开放”和“松散”，所以也许 Joel Brown 可以评论一下？