Firestore待办列表数据库项目与任务关联结构选型及性能对比

性能差异说明 #

这两种方案在常规场景下性能差异极小：

• 方案1是直接读取嵌套集合users/{userid}/projects/{projectid}/tasks/，属于一次定向查询，文档型数据库会直接定位到该路径下的所有任务文档。
• 方案2是通过users/{userid}/tasks集合加where('projectid', isEqualTo: xxx)过滤，只要给projectid字段建立索引，查询速度和方案1几乎无差别。
  只有当单项目下任务量达到十万级以上时，方案1的嵌套集合可能因路径层级深，在文档索引定位上有极细微延迟，但日常使用完全感知不到。

方案1：嵌套集合结构（tasks嵌套在project下） #

优点 #

• 数据关联性直观，贴合"项目包含任务"的业务逻辑，查询项目任务时路径清晰，无需额外关联字段。
• 天然实现项目级数据隔离，删除项目时可直接删除整个tasks子集合，无需遍历所有任务筛选删除。
• 权限控制更简单，只需给projects/{projectid}/tasks设置规则，就能统一管控该项目下所有任务的访问权限。

缺点 #

• 任务无法跨项目复用，若有需要同时属于多个项目的任务，这种结构完全无法支持。
• 全局查询任务（比如查询用户所有未完成任务）需要遍历所有项目的tasks子集合，多次查询叠加，效率极低且代码复杂。
• 单项目任务量过大时，嵌套集合的文档读取会占用更多内存，分页逻辑也会更复杂。

方案2：扁平化集合（独立tasks集合+projectid引用） #

优点 #

• 任务全局查询极为高效，比如查询用户所有未完成任务，只需一次where('status', isEqualTo: 'unfinished')即可完成。
• 支持任务跨项目关联，只需给任务添加多个projectid数组字段就能实现（需调整对应索引）。
• 集合结构更灵活，后续扩展任务的其他关联关系（比如关联标签、优先级分组）时，无需调整嵌套层级。

缺点 #

• 删除项目时，需要单独查询所有关联任务并删除，多了一次查询操作；如果用云函数批量删除，会增加额外运维成本。
• 权限控制需要同时管控projects和tasks集合，要确保任务的projectid属于用户有权访问的项目，规则逻辑更复杂。
• 数据关联性不如嵌套结构直观，新手开发时容易出现projectid引用错误的问题。

更优方案：混合结构 #

结合两种方案的优势，推荐采用扁平化为主，嵌套为辅的混合结构：

1. 核心任务数据存在独立的users/{userid}/tasks集合，保留projectid字段用于关联项目。
2. 在users/{userid}/projects/{projectid}下创建一个taskIds子集合，只存储该项目关联的任务ID列表。

优势 #

• 既保留了方案2的全局查询效率，又能通过taskIds快速获取项目下的任务ID，再通过where('id', whereIn: taskIds)批量读取任务详情。
• 删除项目时，只需删除taskIds子集合，再通过云函数异步删除关联任务，避免同步删除的性能问题。
• 权限控制可以通过taskIds的访问规则，间接管控任务的访问权限，逻辑更清晰。

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