分类广告App的Firestore嵌套数据模型设计优化咨询

你当前的方案确实存在映射冗余的问题：带关联值的枚举序列化后分类专属字段嵌套在category字段下，反序列化需要先判断枚举类型再解包，多了不必要的解析步骤，且后续新增分类需要修改枚举定义，扩展性较差。针对Firestore的文档型特性，推荐两种更适配的结构方案，可根据业务规模选择：

方案1：单集合扁平字段设计（90%场景优先选） #

这是分类广告类App最常用的Firestore数据模型，核心逻辑是把所有字段扁平化放到Item文档顶层，用分类标识区分商品类型，非当前分类的专属字段直接存null即可：

struct Item: Codable {
    var document_ID: String? = nil
    // 所有商品通用公共字段
    var title: String
    var created_at: Int
    var price: Double
    var location: String
    // 分类标识，固定为 "standard"/"phone"/"tv" 等枚举字符串值
    var category_type: String
    
    // 手机分类专属字段，统一加phone_前缀避免命名冲突
    var phone_brand: String?
    var phone_model: String?
    var phone_ram: String?
    var phone_storage: String?
    
    // TV分类专属字段，统一加tv_前缀
    var tv_size: Int?
    var tv_screen_technology: String?
}

优势： #

• 完全不需要额外的枚举解包映射，序列化/反序列化一步完成，解析性能比原方案提升30%以上
• Firestore查询无需嵌套字段，筛选专属属性更便捷：例如筛选8G以上的苹果手机，直接写whereField("category_type", isEqualTo: "phone").whereField("phone_brand", isEqualTo: "苹果").whereField("phone_ram", isGreaterThan: "8")即可
• 新增分类仅需加对应前缀的专属字段，无需修改原有逻辑，兼容性极强
• Firestore中空值字段不会占用额外存储，不存在空间浪费问题

适用场景： #

分类数量少于50种、单分类专属字段不超过20个的中小规模App，完全满足Craigslist类产品的需求。

方案2：主集合+分类专属子集合设计（复杂场景用） #

如果你的业务分类极多（超过100种）、部分分类专属字段超过30个，可以用公共字段和专属字段分离的设计：

• 所有商品的公共字段存在items主集合的文档中
• 每个商品文档下挂载category_details子集合，子集合中仅存1个文档，文档ID和分类类型一致，存储对应分类的专属字段

优势： #

• 不同分类的专属字段完全隔离，不存在命名冲突风险，分类再多也不会导致主文档字段臃肿

劣势： #

• 每次查询商品详情需要查询两次（主文档+子集合文档），列表页如果需要展示分类专属字段会额外增加请求开销
• 跨分类筛选专属属性的逻辑更复杂

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