Firestore数据建模指南：嵌入式文档与引用（附博客案例研究）
内容提要
Firestore作为NoSQL文档数据库，设计时应以读取模式而非写入模式为基准，核心是反规范化，通过嵌入或引用减少读取次数，但需注意1MB文档限制、复合索引和热点问题。关系建模涵盖1-1、1-N和N-N，常用子集合、根集合引用或ID数组实现，避免深层嵌套和自增ID，并同步设计安全规则。
延伸解读
从SQL思维转向NoSQL思维
本文强调，从关系型数据库转向Firestore时，最大的挑战是思维模式的转变。SQL通过规范化和JOIN来减少冗余，但读取成本高；而Firestore则相反，通过反规范化（如复制作者姓名到每篇文章）来优化读取，但写入和同步成本更高。理解这一核心差异，是设计高效Firestore数据模型的第一步。
嵌入与引用的选择标准
选择嵌入还是引用，关键在于数据量的大小和增长性。嵌入适合小型、有界的数据（如标签），而引用（子集合或根集合）适合无界增长的数据（如评论）。此外，是否反规范化某个字段，取决于同步成本：计数器（如点赞数）通过原子递增更新，成本低；而复制值（如作者名）每次变更都需要传播到所有副本，因此仅适合低频变化的数据。
关系建模的实用模式
对于1-N关系，子集合适合通过父文档查询的场景，根集合引用适合独立查询子项的场景。对于N-N关系，联合集合（类似SQL的中间表）是最灵活的方式，而ID数组适合小规模且查询方向固定的关系。混合模式（数组+联合集合）是实践中最常见的，兼顾了读取效率和灵活性。
避免常见陷阱
设计时需注意：避免深层嵌套（超过2-3层），防止查询和安全规则复杂化；避免自增ID，以防热点问题；提前规划复合索引，避免生产环境报错；注意单文档写入速率限制（约1次/秒），高并发场景使用分片计数器；安全规则应与数据模型同步设计，否则后期难以精确控制访问权限。
Q&A
Firestore数据建模的核心原则是什么？
核心原则是“为读取而建模，而不是为写入而建模”。这意味着在设计数据结构时，应优先考虑应用如何查询和显示数据，而不是如何写入。通常通过反规范化（如嵌入或引用）来减少读取次数，优化读取性能。
在Firestore中，嵌入和引用有什么区别？各自适用于什么场景？
嵌入是将相关数据直接存储在父文档中，优点是单次读取即可获取所有数据，但受1MB文档大小限制，适合小型、有界的数据列表（如文章标签）。引用是将数据拆分到不同集合或子集合，并故意复制部分字段以避免额外读取，适合动态、快速增长的数据（如评论、订单历史），但需要处理数据同步问题。
在Firestore中如何建模一对多关系？
一对多关系有三种主要建模方式：1）使用子集合（如posts/{postId}/comments），适合总是通过父文档查询子数据且数据量大的场景；2）使用根集合加引用字段（如comments集合中存储postId），适合需要独立查询子数据的场景；3）使用嵌入式数组，仅当数据量小且有界时使用。
在Firestore中如何建模多对多关系？
多对多关系有三种常见模式：1）连接集合（junction collection），类似SQL的中间表，存储两个实体的ID和额外属性；2）双向ID数组，在双方文档中存储对方ID数组，适合小规模列表；3）混合方法，结合数组和连接集合，根据查询频率和变化频率选择。
Firestore中避免热点问题的方法是什么？
避免热点问题的方法包括：不要使用自增ID，让Firestore生成随机均匀分布的ID；对于频繁更新的文档（如全局计数器），使用分片计数器，将计数分散到多个子文档，读取时汇总。
在Firestore中，为什么需要设计复合索引？
当查询涉及多个where条件，或where与orderBy组合时，需要复合索引。设计时应提前规划，避免在生产环境中才发现缺失索引，Firestore的错误信息会提供自动生成索引的链接。
在博客案例中，为什么评论使用子集合而点赞使用根集合？
评论总是与文章一起读取，且数量可能很大，所以使用子集合（posts/{postId}/comments）便于通过文章查询。点赞需要按用户和文章双向查询（如检查某用户是否点赞某文章），所以使用根集合（likes）并存储postId和userId，以便建立索引进行双向查询。
