在NoSQL中按时间戳组织分组的数据结构设计问询

当前设计的问题 #

• 目标追溯逻辑复杂易出错：你提到的场景——用户仅在05.02.22设置过目标，后续未修改时，要查11.02.22的目标就得手动推算，不仅查询代码写起来麻烦，还容易因为漏记临时目标变更导致数据错误。
• 数据冗余且一致性难维护：用户的追踪时长同时存在Users和Groups两个集合里，两处维护同一份数据，万一更新时漏了其中一边，就会出现数据不一致的情况，后期排查成本很高。
• 嵌套结构扩展性差：像timeTracked用键值对存日期和时长，随着时间推移这个对象会越来越大，要做时间范围统计（比如近7天总时长）时，需要遍历整个对象，效率极低，后续新增统计类功能会非常受限。

优化后的结构（以MongoDB为例，通用NoSQL思路） #

1. 用户集合（Users） #

只存储用户基础信息和关联分组，剥离时长、目标这类动态数据：

{
  "_id": "user1_unique_id",
  "name": "user1",
  "groups": ["group1_id", "group2_id"] // 仅存储分组ID引用
}

2. 用户每日目标集合（UserDailyGoals） #

专门管理用户目标，两种存储方式按需选择：

方式一：按生效时间段存储（适合用户常设置长期固定目标）

{
  "_id": ObjectId(),
  "userId": "user1_unique_id",
  "targetMinutes": 80,
  "startDate": ISODate("2023-02-05T00:00:00Z"), // 目标生效起始日期
  "endDate": ISODate("2023-02-11T23:59:59Z") // 目标截止日期，未修改则设为未来日期
}

用户修改目标时，将上一条记录的endDate改为修改前一天，再新增一条新目标记录。查询某日期目标时，只需筛选startDate ≤ 查询日期 ≤ endDate的记录即可。

方式二：按日期单独存储（适合每日可能修改目标的场景）

{
  "_id": ObjectId(),
  "userId": "user1_unique_id",
  "date": ISODate("2023-02-05T00:00:00Z"),
  "targetMinutes": 80
}

用户设置默认目标时，可批量生成未来N天的记录；修改目标时直接更新对应日期的记录。查询时按userId和date直接匹配，无需推算。

3. 用户追踪时长集合（UserDailyTrackedTime） #

单独存储每日追踪时长，当日时长递增时直接更新对应记录：

{
  "_id": ObjectId(),
  "userId": "user1_unique_id",
  "date": ISODate("2023-02-11T00:00:00Z"),
  "trackedMinutes": 45,
  "updatedAt": ISODate("2023-02-11T14:30:00Z") // 记录最后更新时间，便于排查
}

4. 分组集合（Groups） #

仅存储分组基础信息和成员ID，不掺和时长、目标数据：

{
  "_id": "group1_unique_id",
  "name": "group1",
  "members": ["user1_id", "user2_id"]
}

常用查询示例 #

• 查询用户某日的目标与进度：同时查询UserDailyGoals（匹配对应日期的目标）和UserDailyTrackedTime（匹配当日时长），直接计算完成率。
• 查询分组内所有成员当日进度：先从Groups获取成员列表，再批量查询每个成员的当日目标和时长，聚合后展示即可。

优化核心优势 #

• 避免数据冗余，消除多集合数据不一致的风险，更新操作只需维护单个集合。
• 目标查询无需推算，无论用户是否修改目标，都能快速定位对应日期的目标值。
• 扩展性强，后续新增周/月统计、多维度目标分析等功能，直接基于现有集合做聚合查询即可。

内容的提问来源于stack exchange，提问作者Fredyonge