新设备登录已有账号时，设备端应如何存储groupId？

背景 #

• 用户数据存在users集合，群组数据存在groups集合
• 当前业务规则：用户隶属于一个群组，登录时需选择加入或创建群组
• 注册流程：通过SharedPreferences存储用户的groupId
• 已实现的嵌套结构：groups -> groupId -> users，用于快速获取群组内用户列表

核心疑问 #

用户使用新设备登录已有账号时，设备端该如何获取并存储对应的groupId？

我的现有思路及顾虑 #

• 思路1：在用户模型中添加groupId字段
  • 好处：登录拉取用户详情时可直接拿到groupId，无需额外查询
  • 顾虑：未来可能需要支持用户加入多个群组，单groupId的设计扩展性不足
• 思路2：创建homeUsers集合（受SQL思维影响）
  • 顾虑：违背NoSQL设计初衷，会增加数据冗余和系统复杂度

1. 用户模型维护群组关联（推荐） #

在users集合的用户文档中添加两个字段：

• groupIds: 数组类型，存储用户加入的所有群组ID（初始时仅包含一个）
• currentGroupId: 字符串类型，记录用户当前活跃的群组ID

登录时拉取用户文档，将currentGroupId存入本地SharedPreferences即可。这种设计既满足当前单群组需求，未来支持多群组时只需往groupIds里追加ID，同时通过currentGroupId快速定位用户当前使用的群组，完全兼容业务扩展。

2. 利用现有嵌套集合反向查询（备选） #

基于已有的groups -> groupId -> users结构，登录后查询所有包含当前用户ID的群组文档。如果是单群组场景，直接取返回的唯一groupId存入本地；如果未来扩展到多群组，可让用户手动选择默认群组，或取创建时间最早/最近访问的群组作为默认值。但这种方式查询效率低于方案1，尤其是用户加入多个群组时，不推荐作为首选。

3. 放弃SQL式冗余集合 #

不要创建homeUsers这类集合，NoSQL的核心是为查询效率合理冗余数据，而非模仿SQL的关系模型。直接在用户文档中维护群组关联，是更贴合NoSQL设计思想的做法，能避免不必要的复杂度。

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