Firestore大型多对多关系（含访问列表）是否应复制访问列表到子节点

遗漏的建模方式 #

• 用户专属工单索引集合：为每个用户创建users/{uid}/accessible-tickets子集合，存储用户可访问工单的精简数据（或仅工单ID+核心字段），由Cloud Functions在工单创建、权限变更时自动同步。首页直接查询该集合，一次请求即可获取所有可访问工单，彻底规避多查询问题，代价是额外存储成本和同步维护工作。
• 权限组中间层建模：新增groups集合，每个组对应一组项目权限（如group-dev关联projectA和projectB），用户文档存所属组引用，工单文档存关联组引用。权限验证时，安全规则只需检查用户是否在工单关联组内；更新权限时仅需修改组成员，无需逐个更新工单或用户权限列表，适配权限层级复杂、用户批量变动频繁的场景。
• 用户-项目权限映射集合：单独建立user-project-permissions集合，文档ID采用{uid}-{projectId}格式，存储用户对项目的权限详情。首页先查该集合获取用户所有有权限的项目ID，再拆分多个in查询（每个in最多30个ID）并行执行后合并结果，既突破方案B的30个项目限制，又避免方案C的冗余存储。

方案C的其他未考虑弊端 #

• 存储成本剧增：每个工单复制完整项目访问列表，若单项目有100个用户、500条工单，仅用户引用就会产生50000条存储条目，随着规模扩大，存储成本会远超其他方案。
• 文档大小超限风险：Firestore单文档最大1MB，若项目访问用户较多（如几百个），工单的duplicatedAccessList会占用大量空间，可能触发文档大小限制，导致工单无法创建或更新。
• 权限变更一致性隐患：批量更新项目权限时，Cloud Functions需遍历所有项目工单逐一更新，若工单量极大，易出现部分更新成功、部分失败的情况，需额外开发定时校验、补偿更新机制，维护复杂度陡增。
• 权限泄露窗口：Cloud Functions同步存在延迟，用户被移除项目权限后，工单的duplicatedAccessList未及时更新的这段时间内，用户仍可访问本该无权查看的工单，存在权限泄露风险。
• 批量操作性能瓶颈：Firestore批量写入最多支持500次操作，若项目工单超500条，权限变更需拆分多个批量任务，耗时显著增加，进一步拉长数据不一致的窗口。

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