Firestore中用户订阅历史应存于用户集合内还是外？

方案一：将订阅作为用户集合的嵌套子集合 #

优势 #

• 数据关联直观：查询特定用户的订阅历史时，直接通过路径users/{userId}/subscriptions即可获取，无需额外添加userId过滤条件
• 权限管控简单：Firestore安全规则可直接基于父用户文档的权限逻辑，限制用户仅能访问自己的订阅记录，无需单独配置订阅集合的规则
• 原子性操作方便：更新用户信息与添加订阅记录可在同一事务中完成，保障数据一致性

劣势 #

• 全局查询受限：无法高效完成跨用户的批量查询（比如统计所有过期订阅、某套餐的总订阅量），这类操作需要遍历所有用户集合，性能极低
• 扩展性不足：若后续需给订阅添加关联数据（如支付凭证、优惠券），嵌套结构会让数据模型变得臃肿，难以维护
• 单用户数据量上限：虽无硬性文档数量限制，但单个用户订阅记录过多（如数百条以上）时，查询分页与性能会受到影响

方案二：创建独立的订阅集合 #

优势 #

• 全局查询灵活：可直接在subscriptions集合上执行各类批量查询（如筛选即将到期的订阅、按支付ID查找记录），效率更高
• 数据结构清晰：订阅作为独立业务实体，后续扩展字段或关联其他集合（如支付方式、优惠券）更便捷
• 性能优化空间大：可针对订阅的常用查询单独创建索引，避免影响用户集合的查询性能

劣势 #

• 查询单个用户订阅需额外过滤：需在订阅文档中添加userId字段，查询时通过subscriptions.where('userId', isEqualTo: currentUserId)获取
• 权限规则需单独配置：安全规则中需校验订阅文档的userId与当前用户ID一致，确保用户仅能访问自己的订阅
• 原子性操作需手动保障：若需同时更新用户信息与订阅记录，需通过Firestore事务来实现数据一致性

方案选择建议 #

• 若你的业务仅聚焦单个用户的订阅管理，几乎不需要全局统计或跨用户查询，且单用户订阅记录不会太多（几十条以内），可以选择嵌套子集合
• 若业务存在全局订阅统计、批量操作（如过期提醒）、后续扩展订阅功能的需求，或预计单用户订阅记录会较多，优先选择独立集合

实际开发中，绝大多数订阅系统都会采用独立集合方案，因为业务后期几乎都会产生全局查询的需求，嵌套结构会严重限制业务扩展性。

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