mongodb - Mongo 架构 : Todo-list with groups

Question

我想学习 mongo 并决定为学习目的创建一个更复杂的 todo 应用程序。

基本思想是一个任务列表，其中任务在文件夹中分组。用户可能对这些文件夹具有不同的访问权限(读取、写入)，并且任务可能会移动到其他文件夹。通常(尤其是同步)任务将按文件夹而不是单独请求。

基本上我想到了三种方法，并想听听您对它们的意见。也许我错过了一些要点，或者只是思维方式错误。

A - 引用文献列表

收藏:User , Folder , Task

Folders包含对 Users 的引用

Folders包含对 Tasks 的引用

问题

更新 Task 时引用 Folder需要。这些引用要么存储在任务中(冗余)，要么必须与每个 API 调用一起传递。

B - 子文档

收藏:User , Folder

Folders包含对 Users 的引用

Tasks是 Folders 内的子文档

问题

无法更新 Task不知道Folder .两者都需要传输，但与 A 相比没有冗余。

C - 引用文献

收藏:User , Folder , Task

Folders包含对 Users 的引用

Tasks保留对他们的 Folders 的引用

问题

请求文件夹意味着在长列表中搜索，而不是直接引用 (A) 或仅返回文件夹 (B)。

Answer 1

如果除了名称之外不需要文件夹的任何元数据，您也可以使用:

收藏:User , Task

Task有字段folder

User有数组 read_access和 write_access

然后

您可以获得所有文件夹的列表

db.task.distinct("文件夹")

当您检索用户文档时，会自动检索特定用户可以访问的文件夹，以便在登录时基本可以知道这些文件夹。

您可以获得用户可以阅读的所有任务

db.task.find( { 文件夹: { $in: read_access } } )

与 read_access beeing 您从用户文档中获得的相应数组。与 write_access 相同.

您可以通过对文件夹名称的简单查找查询来查找文件夹中的所有任务。

重命名文件夹可以通过对每个集合的一个更新查询来实现。

也可以通过简单的方式创建文件夹或将任务移动到另一个文件夹。

所以没有文件夹的元数据，这就是我要做的。如果您需要文件夹的元数据，它可能会变得稍微复杂一些，但基本上您可以使用包含元数据的文件夹集合来管理那些独立于上述任务和用户的文件夹集合 _id正在使用 user 中引用的文件夹名称和 task .

编辑:

不同方法的比较

偶然发现 this link您可能会感兴趣。其中讨论了从关系数据库模型过渡到 mongo。不同之处在于，在关系数据库中，您通常会尝试使用 third normal form目标之一是避免偏向任何形式的访问模式，在 mongodb 中，您可以尝试对数据进行建模以最适合您的访问模式(同时记住不要通过冗余引入可能的数据异常)。

所以考虑到这一点:

您的型号 一个 是一种如何在关系数据库中执行此操作的方法(通过 id 引用的一个表中的每种类型的信息)

型号 乙 将针对访问模式量身定制，在这种模式下，您始终列出完整的文件夹，并且仅在打开文件夹时才编辑任务(如果您检索一个文件夹，则无需额外查询即可完成所有任务)

C 将是与 不同的关系模型一个 我认为更接近第三范式(不知道确切的表格)

我的建议是支持文件夹访问不如 优化。乙 但可以更轻松地显示和编辑单个任务

模式可能出现的问题:自 一个 和 C 基本上是相关的，您可能会遇到外键问题，因为 mongodb 不强制执行外键约束(例如，您可以删除一个文件夹，而在 C 中仍有任务引用它，或者一个任务而不删除它在文件夹在 A 中)。您可以通过从应用程序强制执行来规避此问题。对于 乙 通过允许文件夹在达到特定任务数时拆分为多个文档，16MB 文档限制可能成为可以规避的问题。

所以新结论:我认为 一个 和 C 可能不会向您展示 mongodb 的优点(在 mongodb 中构建的工作甚至可能比在 sql 中构建的工作更多)，因为它们是您在传统关系数据库上所做的事情，而 mongodb 并非设计用于(例如缺少的 join 语句) ，没有外键约束)。总而言之 乙 大多数匹配您的访问模式“通常(尤其是同步)任务将由文件夹请求”，同时仍然允许在文件夹打开后轻松编辑和移动任务。