Firestore：子集合与根级集合存储方案对比咨询

方案1：每个分类对应独立根级集合（如music_questions、sports_questions） #

优点 #

• 单分类读取效率直接：查询某类问题时无需额外层级跳转，直接查询对应根集合即可，逻辑简单，单次操作就能获取目标数据，性能无额外开销。
• 单分类操作逻辑简洁：统计分类题量、分页加载问题时，直接对根集合执行count()或分页查询，代码实现更直观。
• 权限控制粒度更细：可针对不同分类集合单独配置安全规则，比如限制特定用户组访问某类问题，规则配置更灵活。

缺点 #

• 扩展性差：分类数量增多后，根集合会变得杂乱，新增分类需手动创建新集合，代码中要维护多个集合引用，易出现疏漏。
• 跨分类查询成本高：若需随机抽取多分类题目，需发起多个集合查询并合并结果，不仅代码复杂，还会增加读取次数（每个分类查询算一次读取），提升成本。
• 分类元数据管理分散：无法在集合层级统一存储分类名称、描述等元数据，需额外维护一份分类信息集合，否则无法快速获取全部分类列表。

方案2：根级集合categories+分类文档内嵌questions子集合 #

优点 #

• 结构规整易维护：所有分类集中在一个根集合，新增分类仅需添加一个categories文档，无需创建新集合，代码只需维护一个根集合引用，扩展性强。
• 分类元数据统一存储：分类名称、图标、难度标签等元数据可直接存在对应分类文档中，查询分类列表时能一次性获取所有信息，无需额外存储。
• 跨分类查询灵活：可通过集合组查询（collectionGroup('questions')）直接检索所有分类的问题，或先获取分类列表再批量查询子集合，逻辑统一且代码简洁。

缺点 #

• 单分类读取多一层逻辑：查询某类问题时需先定位到对应分类文档，再进入子集合查询，虽然Firestore底层性能不受影响，但代码中多了一层引用逻辑。
• 集合组查询需提前配置索引：使用集合组查询跨分类问题时，必须提前创建对应索引，增加了配置成本。
• 权限控制关联度高：若要限制某类问题的访问，需同时配置分类文档和子集合的安全规则，规则逻辑相对复杂。

关于读取成本与速度的补充 #

• 读取成本一致：Firestore按读取的文档数量计费，无论文档在根集合还是子集合，每读取一个文档都算一次计费单位，两种方案的单文档读取成本无差异。
• 查询速度无明显区别：Firestore底层存储是扁平结构，子集合仅为逻辑层级，并非物理嵌套，因此两种方案的查询延迟几乎相同。
• 场景适配建议：若游戏核心场景是单分类刷题，方案1更合适；若需多分类随机出题、频繁新增分类，方案2的扩展性和灵活性更优。

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