从Supabase迁移至Firebase：高可读性低成本数据结构设计问询

一、产品数据：尺寸、图片的存储决策 #

优先选嵌入的场景 #

• 尺寸、图片是产品的核心属性，几乎每次拉取产品数据都要用到（比如商品详情页必展示），且总数据量远低于Firestore单文档1MB上限（就算实际属性更多，只要整体大小可控）。这种情况嵌入更高效，一次读取就能拿到全量数据，减少请求次数、降低延迟。
• 尺寸、图片更新频率极低（比如产品上架后基本不改尺寸，图片仅偶尔替换），嵌入的维护成本可以忽略。

优先选子集合的场景 #

• 尺寸、图片数据量极大（比如单产品有几十张高清图，或尺寸参数条目繁多），接近甚至超过1MB限制，必须拆分。
• 需要单独操作这类数据：比如后台批量更新某类产品的尺寸，或商品详情页分页加载图片（先加载主图，滚动后加载附图），子集合支持单独查询、修改，不影响产品主文档。
• 团队协作维护时，子集合在Firebase控制台结构更清晰，能快速定位修改特定数据，降低误操作主文档的风险。

二、账号关联数据的存储选择 #

嵌入主文档的情况 #

• 关联数据是账号的基础属性，比如用户默认收货地址、少量常用支付方式，每次获取账号信息都要用到，且数据量小、更新不频繁，嵌入主文档更省心，一次读取就能拿到所有常用信息。
• 像用户的基础偏好设置（深色模式、语言选择）这类数据，完全可以直接嵌在用户主文档里。

用子集合的情况 #

• 关联数据是多条目且独立的类型，比如用户的订单记录、收藏商品列表、浏览历史。这类数据会持续新增，数量可能很大，且经常需要单独查询（比如拉取用户最近30天的订单），子集合能避免主文档体积膨胀，还支持分页、条件查询等操作。
• 需要精细化权限控制：比如用户订单只能自己查看，子集合可以单独设置安全规则，比在主文档嵌套数组的权限控制更灵活。

总的来说，核心判断标准就是三个：数据是否需要和主文档频繁一起读取？数据量是否会持续增长？是否需要单独操作？ 不用拘泥于单一方式，混合使用是Firestore数据设计的常态。

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