【问题标题】:What's is recommended for a To-Do List schema design for MongoDB?对于 MongoDB 的待办事项列表架构设计,推荐什么?
【发布时间】:2013-10-13 13:05:22
【问题描述】:

以发布任务为主要目的,显示为“待办事项”或“已完成”,如何更好地构建以下对象的 NoSQL 数据库:

  • 创建日期时间不为空
  • 任务 ID 不为空
  • 任务 ID 作为 Str Not Null
  • 任务标题非空
  • 任务说明
  • 到期时间和/或日期
  • 用户不为空
    • ID 不为空
    • ID 作为 Str Not Null
    • 名称​​不为空
    • 用户名非空
    • 位置
    • 联系人计数
    • 创建日期不为空
    • UTC 偏移量非空
    • 时区 非空
    • 地理启用非空
    • 已验证
    • 任务计数非空
    • 语言非空
  • 地理位置
    • 坐标
    • 地点
  • 与谁共享
    • ?
  • 任务状态
    • 标记完成
    • 自动移动到完成(因为 datetime-due 已过)
    • 标记(真/假)
    • 已编辑
    • 编辑计数
    • 编辑日期时间
    • 已删除

用户可以发布无限数量的任务,并且任务可以在用户之间共享。如何最好地捕捉这种关系?

任务可以手动“标记为完成”,或“自动标记”和“自动移动完成”,因为到期日期已过。

编辑和删除也将被记录下来。

首先,以下架构的优点和/或缺点是什么(主要关注可扩展性):

{
   "created_at":"Day Mon ## 00:00:00 +0000 20##",
   "id":#####,
   "id_str":"#####",
   "title":"This is a title",
   "description":"The description goes here..",
   "date_due":"Day Mon ## 00:00:00 +0000 20##",
   "user":{
      "id":####,
      "id_str":"####",
      "name":"Full Name",
      "user_name":"Username",
      "location":"",
      "contacts_count":101,
      "created_at":"Day Mon ## 00:00:00 +0000 20##",
      "utc_offset":####,
      "time_zone":"Country",
      "geo_enabled":true,
      "verified":false,
      "task_count":101,
      "lang":"en",
   },
   "geo":?,
   "coordinates":?,
   "place":?,
   "shared_with":?,
   "moved_done":false,
   "marked_done":false,
   "edited":false,
   "deleted":false,
}

【问题讨论】:

    标签: mongodb database-design schema database nosql


    【解决方案1】:

    编辑和删除也将被记录下来。

    您是否只需要知道一项任务已被更改,而不是如何更改或由谁更改?

    否则,这可能需要版本控制,即对于每个 Task,可以有多个 TaskVersions。或者,您可以仅存储修改 - 这取决于您的需要。特别是,由于锁定,拥有许多写入者并不容易——如果两个人试图“同时”更改同一个对象怎么办?您可能需要考虑乐观与悲观锁定或 mvcc。请注意,必须仔细设计“任务可以在用户之间共享”要求。

    首先,以下架构的优点和/或缺点是什么(主要关注可扩展性):

    我猜user 指的是登录的用户。我不会对这些信息进行非规范化处理。假设用户创建了一千个任务并添加了一个新联系人。现在必须更新 1000 个文档的contacts_count,否则会出错。仅对真正需要的部分进行非规范化,例如user_name

    根据您显示的列表类型,您还可以选择仅存储用户 ID,并在需要显示用户名时实际获取用户对象。虽然不支持复杂的联接,但对 50 或 100 个 id 进行 $in 查询(就像您必须在任务列表中查询一样)非常快。

    【讨论】:

    • 您能否详细说明一下关于“用户名”的非规范化概念?感谢您的概念检查.. 对于 TaskVersions,最初可能会坚持只存储/更新修改,尽管如何和谁将是记录.. 在必要时作为 user_id 的函数获取用户对象似乎最好,谢谢
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-01-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-10
    相关资源
    最近更新 更多