Question

我正在构建一个应用程序，允许用户执行一些“任务”来获得积分。 “任务”是“活动”的一部分，“活动”本身就是“品牌”的一部分。我对用于存储用户响应的模式感到困惑。这就是我建立的。所有任务都有一些用户需要完成的活动才能完成任务。

{ _id : ObjectId,
  user_id : ObjectId,
  campaign : [ 
        { _id : ObjectId,
          campaign_id : ObjectId,
          brand_id : ObjectId,
          completed : Boolean,
          points : Number,
          tasks : [
             { _id : ObjectId,
               task_id : ObjectId,
               start_time : Date,
               rewards : points,
               responses : [
                     { _id : ObjectId,
                       activity_id : ObjectId,
                       response : Mixed, 
                    }...]
             }...]
       }...]
}

查询：
1.插入新的响应并更新多少个。做特定任务的人的人。
2.完成任务和用户各自的奖励 3.完成用户的完整活动 4.更新用户对任务的响应 5.找到所有用户对特定活动的独特回复。

问题：
1.问题是这个模式包含嵌套数组，mongodb不允许我在1级之后使用位置运算符。

如果有人可以建议可以更好地执行这些查询的设计，那将会很有帮助。

编辑：

我已将上述集合分解为两个集合，以方便查询系统，同时保持权利应存在于系统中的意义。

集合1：user_tasks（存储用户尝试的广告系列和任务）

{ _id :ObjectId,
  user_id : ObjectId,
  campaigns : [ 
       { _id : ObjectId,
          campaign_id :ObjectId,
          completed : Boolean,
          points : Number,   
          tasks : [ObjectId]
       }...]
}

集合2：user_responses

{ _id : ObjectId,
  user_id : ObjectId,
  task_id : ObjectId,
  rewards : Number,
  responses :[
        { _id : ObjectId,
          activity_id : ObjectId,
          response : Mixed
        } ... ]
}

这使我有一个更简单的查询系统，专门用于更新和插入响应以及计算特定任务的排行榜。

Answer 1

我会创建专门用于任务和响应的集合。将要求您在服务器端编写一些“关系管道”逻辑。这是使用MongoDB的代价。一些图书馆提供帮助以帮助您（例如Mongoose的populate运营商）。

拥有大直径的集合图确实有一些缺点，因为它可能会使您的查询更复杂，并且需要在MongoDB客户端和数据库之间进行更多往返。因此，确实有动机使用子文档而不是外部集合。

如何在拥有一个整体收藏品和太多光线收藏品之间取得中间地位？以下是一些问题要问自己：

我是否有超出文件大小限制的风险？
在我的信息模型中，父实体是否应该了解子实体，或者它是否存在并且没有它们才有意义？
我是否在客户端构建了一个完整的 ad hoc 查询/索引引擎，只是为了访问子文档？

Answer 2

你必须颠倒你的设计。基本上以任务为中心。

您的数据库中有4个主要馆藏。

用户
任务
品牌
广告活动

通过这样做，您可以毫不费力地扩展，同时，您的数据管理将变得轻而易举。

Mongodb架构设计验证

2 个答案: