Mongo架构:带有组的待办事项列表

K. *_* D. 8 mongodb nosql

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

基本思想是任务列表,其中任务分组在文件夹中.用户可以对这些文件夹(读取,写入)具有不同的访问权限,并且可以将任务移动到其他文件夹.通常(特别是对于同步)任务将由文件夹而不是单独请求.

基本上我考虑了三种方法,并希望听取您对他们的意见.也许我错过了一些观点或者只是错误的思考方式.

A - 参考文献清单

  • 类别:User,Folder,Task
  • Folders 包含对的引用 Users
  • Folders 包含对的引用 Tasks

问题

  • 更新Task引用时Folder需要.这些引用都存储在Task(冗余)中,或者必须在每次API调用时传递.

B - 子文件

  • 收藏:User,Folder
  • Folders 包含对的引用 Users
  • Tasks 是其中的子文档 Folders

问题

  • 无法在Task不知情的情况下更新Folder.两者都需要传输,但与A相比没有冗余.

C - 参考文献

  • 类别:User,Folder,Task
  • Folders 包含对的引用 Users
  • Tasks保持对他们的参考 Folders

问题

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

Tru*_*ert 7

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

  • 收藏:User,Task
  • Task 有领域 folder
  • User有数组read_accesswrite_access

然后

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

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

  • 检索用户文档时,将自动检索特定用户可以访问的文件夹,以便在登录时基本知道这些文件夹.

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

    db.task.find({folder:{$ in:read_access}})

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

  • 您可以使用文件夹名称的简单查找查询找到文件夹中的所有任务.

  • 可以使用每个集合上的一个更新查询来重命名文件夹.

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

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


编辑:

比较不同的方法

偶然发现了这个可能对您感兴趣的链接.在讨论从关系数据库模型转换到mongo.不同之处在于,您通常会尝试将关系数据库用于第三种常规形式,其中一个目标是避免偏向任何形式的访问模式,在mongodb中,您可以尝试对数据建模以最适合您的访问模式(同时请记住,不要通过冗余引入可能的数据异常.

所以考虑到这一点:

  • 您的模型A是一种在关系数据库中执行此操作的方式(通过id引用的一个表中的每种类型的信息)
  • 模型B将针对访问模式进行定制,您总是列出一个完整的文件夹,只有在打开文件夹时才会编辑任务(如果您检索一个文件夹,则无需其他查询即可完成所有任务)
  • C将是一个与A不同的关系模型,我认为更接近第三范式(不知道确切的表)
  • 我的建议是支持文件夹访问不像B那样最优,但可以更容易地显示和编辑单个任务

模式可能出现的问题:由于AC基本上是关系型的,因此你可以解决外键的问题,因为mongodb不强制执行外键约束(例如,你可以删除一个文件夹,同时仍有任务在CC中引用它任务没有删除其在A)文件夹中的引用.您可以通过从应用程序强制执行它来规避此问题.对于B,16MB文档限制可能成为一个问题,因为允许文件夹在达到特定任务计数时拆分为多个文档.

这么新的结论:我认为AC可能不会向你展示mongodb的优势(甚至可能在mongodb中构建比在sql中更多的工作),因为它们是你在传统的关系数据库上所做的,这是mongodb的方式.不是为了设计的(例如缺少连接语句,没有外键约束).在总和B中,大多数匹配您的访问模式"通常(特别是用于同步)任务将按文件夹请求",同时仍允许在文件夹打开后轻松编辑和移动任务.