Firebase数据结构设计咨询：企业车辆设备管理场景

核心设计思路（帮你从关系型转NoSQL） #

先明确几个Firebase设计的关键原则：

• 优先围绕实际查询场景设计：比如你常查某辆车的检查记录，就把记录和车辆绑定
• 子集合适合数量持续增长、独立增删、无需和父文档一起加载的数据
• 小体量、常和父文档联动查询的数据，直接存在父文档字段里更高效

具体结构设计 #

1. 企业（Companies）集合 #

每个企业对应一个独立文档，存储基础信息：

companies/{companyId}
{
  "name": "XX运输公司",
  "address": "XX市XX区",
  "contact": "13XXXXXXXXX"
}

• 无需子集合，企业作为顶层实体，关联的员工、车辆通过字段引用（比如员工文档存companyId）

2. 员工（Drivers）集合 #

每个司机是一个文档，关联所属企业和驾驶车辆：

drivers/{driverId}
{
  "name": "张三",
  "licenseNumber": "A123456",
  "companyId": "company_001",
  "vehicleIds": ["vehicle_001", "vehicle_002"] // 若固定开一辆，直接用"vehicleId": "xxx"
}

• 无需子集合，你的场景里没有司机专属的高频增删数据，基础信息存在主文档即可

3. 车辆（Vehicles）集合 #

车辆是核心实体，用子集合存储每日检查、维护记录（这类数据随时间持续增长）：

vehicles/{vehicleId}
{
  "plateNumber": "京A12345",
  "model": "东风天龙",
  "companyId": "company_001",
  "pumpId": "pump_001", // 绑定所属泵
  "currentMileage": 125000 // 实时更新，方便维护提醒
}

// 子集合：车辆每日检查记录
vehicles/{vehicleId}/dailyInspections/{inspectionId}
{
  "inspectionDate": "2024-05-20",
  "driverId": "driver_001",
  "items": [
    {"name": "刹车系统", "status": "正常", "note": ""},
    {"name": "轮胎磨损", "status": "需更换", "note": "左前轮磨损超阈值"}
  ],
  "createdAt": "2024-05-20T08:30:00Z"
}

// 子集合：车辆维护记录
vehicles/{vehicleId}/maintenanceRecords/{recordId}
{
  "recordDate": "2024-05-15",
  "type": "里程维护", // 可选"周期维护"
  "triggerValue": 120000, // 触发维护的里程/天数
  "content": "更换机油、三滤",
  "cost": 800,
  "createdAt": "2024-05-15T14:20:00Z"
}

• 用子集合的原因：检查、维护记录会不断新增，放在子集合不影响车辆主文档加载速度，查询某辆车的历史记录时更高效

4. 泵（Pumps）集合 #

泵的结构和车辆一致，子集合存每日检查记录：

pumps/{pumpId}
{
  "model": "XX型号离心泵",
  "vehicleId": "vehicle_001", // 绑定所属车辆
  "pipeCount": 50 // 当前连接管道数量
}

// 子集合：泵每日检查记录
pumps/{pumpId}/dailyInspections/{inspectionId}
{
  "inspectionDate": "2024-05-20",
  "driverId": "driver_001",
  "items": [
    {"name": "压力测试", "status": "正常", "note": ""},
    {"name": "密封情况", "status": "正常", "note": ""}
  ],
  "createdAt": "2024-05-20T08:40:00Z"
}

5. 管道（Pipes）集合 #

管道绑定所属泵，子集合存月度检查记录：

pipes/{pipeId}
{
  "pipeNumber": "P001",
  "pumpId": "pump_001",
  "length": 100,
  "installDate": "2023-01-10"
}

// 子集合：管道月度检查记录
pipes/{pipeId}/monthlyInspections/{inspectionId}
{
  "inspectionMonth": "2024-05",
  "inspectionDate": "2024-05-25",
  "status": "正常",
  "note": "无腐蚀、无泄漏",
  "createdAt": "2024-05-25T09:15:00Z"
}

• 虽然最多60根管道，但子集合扩展性更好：后续新增检查人员、附件字段，或单独查询某月份所有管道记录时，比存在数组里更灵活

子集合使用判断标准 #

适合用子集合的场景： #

• 数据量持续增长：比如每日/月度检查、维护记录，随时间累积数量越来越多
• 需要独立查询/增删：比如单独查某辆车近30天的检查记录，子集合可直接按日期过滤，无需加载整个父文档
• 无需和父文档一起加载：用户查看车辆基本信息时，不需要同时加载所有历史记录，子集合可按需查询
• 数据结构复杂/多变：比如检查项后续可能新增字段，子集合文档可单独修改，不影响其他数据

适合存在父文档字段的场景： #

• 数据量小且固定：比如司机驾驶证号、车辆牌照号
• 常和父文档联动查询：比如车辆绑定的泵ID，查询车辆时通常需要关联泵信息
• 无需单独增删：比如企业联系电话，不会频繁修改或新增

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