Firestore习题完成进度统计功能的数据模型设计咨询

先拆解你提的三个初始方案的实际问题 #

• 方案A：直接不推荐。Firestore单文档有1MiB的硬存储上限，把所有用户的作答数据塞到每道题的文档里，用户量稍微上涨就会撞容量红线。而且每次拉取习题基础内容的时候，会顺带读出一堆完全无关的用户作答数据，读写浪费非常严重，你考虑到的新用户维护成本高的问题确实存在，本质是把多对多关系硬塞到单侧实体里，完全不符合Firestore的设计逻辑。
• 方案B：小体量demo能用，长期必踩坑。如果你的平台总共就几十上百道题，暂时不扩展其他功能，把用户作答塞到user文档里勉强能跑，但只要后续习题量涨到上千，或者你需要给每条作答存提交时间、答案、得分、批改状态这类附加信息，很快就会碰单文档容量上限。而且之后要是想查某道题的所有用户作答情况，得遍历全量用户文档捞数据，查询成本根本扛不住。
• 方案C：大方向是对的，注意你集合名拼写有误，应该是responses不是repsonses。但这个方案只存user_id和problem_id两个字段不够，也没做高频查询的冗余优化，直接上线的话每次算进度都要全表扫记录，计数成本高、响应慢。

推荐落地的模型设计 #

完全匹配你要的{x}/{y}进度展示需求，兼顾后续功能扩展，也符合Firestore的性能、成本规则：

现有基础集合保持轻量化，不存无关数据 #

• problems集合：只存习题本身的固有属性，比如题干、选项、正确答案、难度、分类、上架状态就行，不要存任何用户相关的作答数据。你需要的总题量y，不要每次加载页面都count整个集合，单独建一个全局配置文档，存一个total_problems字段，每次新增、下架习题的时候同步更新这个值就行，读的时候一次单文档查询就能拿到，毫秒级响应。
• users集合：只存用户的账号基础属性，比如昵称、注册时间、权限，额外加一个completed_problem_count整数字段，直接存该用户已经完成的习题总数，也就是你要的x值。

新建responses集合存原始作答记录 #

集合里的每个文档，对应单个用户对单道习题的一次有效完成记录，文档ID直接用{user_id}_{problem_id}的格式生成，天然避免同一个用户对同一道题重复生成记录，查询的时候直接拼ID就能定位，不用写复杂的条件查询。
文档核心字段按需配置即可，基础必备的几个：

• user_id：关联的用户文档ID，建单字段索引
• problem_id：关联的习题文档ID，建单字段索引
• is_correct：布尔值，标记作答是否正确，方便后续做正确率统计
• submitted_at：时间戳，记录作答提交时间
• answer_content：存储用户提交的具体答案内容，后续要加判分、错题本功能直接复用

进度计算逻辑，零全表扫描 #

• y值（平台总题数）：直接读全局配置里的total_problems，1次读操作搞定。
• x值（当前用户完成数）：直接读当前用户文档里的completed_problem_count字段，也是1次读操作，两个值拼起来就是你要的x/y展示内容，根本不需要扫responses集合做计数。
• 写入逻辑：用户提交作答、判定为有效完成后，先拼{user_id}_{problem_id}查对应的responses文档是否存在，不存在就写入新的作答记录，同时用Firestore的原子更新给对应用户的completed_problem_count加1，全程不会出现重复计数的问题。怕计数不准的话，加个每天低峰期跑的定时对账任务，用分布式计数逻辑校正下这个字段的数值就行，成本极低。

几个实用的设计提醒 #

• 别拿关系型数据库的三范式硬套Firestore，面向高频查询做小字段的写入冗余，比每次读的时候做全表聚合的成本低几个数量级，这是NoSQL设计的核心思路。
• 如果之后要做「某道题多少人答对」这类统计，同样给problems文档加total_attempts、total_correct这类计数字段，用户提交作答的时候同步做原子更新就行，不要每次实时countresponses集合。
• 所有需要频繁计数的场景，都用「写入时更新冗余计数字段+定时对账校准」的方案，不要依赖实时count，Firestore的全集合count查询不仅贵，数据量大的时候响应也慢，完全不适合面向C端用户的页面展示场景。

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