如何在Firebase Realtime Database中查询用户点赞的汽车属性并设计合理JSON结构

你当前的likes节点是按车辆维度存储点赞关系，所有点赞用户都挂在对应车ID下。这种结构下如果要查询某个用户点赞过的所有车，必须把整个likes节点全量拉取到本地遍历判断，当车辆、用户规模变大后，流量消耗和查询延迟都会极高，完全不适合生产环境。

Firebase Realtime Database 不支持跨节点join查询，设计结构的核心原则是顺着高频查询方向提前存储关联关系，允许适当冗余，不追求关系型数据库的三范式。
结合两个核心业务场景（展示某辆车的所有点赞用户、展示某个用户点赞过的所有车），推荐拆分为三个独立节点，分别承载不同维度的数据：

• cars节点：以车辆ID为键存储车辆核心属性，同时冗余存储点赞总数，避免每次展示点赞数时都拉全量点赞用户列表计算。注意不要直接按数组格式存车辆数据，必须用车辆唯一ID作为子节点键，避免后续删除、更新车辆时出现索引错乱。
• likes节点：保留车维度的点赞关系，用于车辆详情页查询对应点赞用户。
• userLikes节点：新增用户维度的点赞关系，用于查询单个用户的所有点赞车辆。

整体结构示例：

{
  "cars": {
    "car_1": {
      "id": 1,
      "title": "BMW",
      "likeCount": 123
    },
    "car_2": {
      "id": 2,
      "title": "Toyota",
      "likeCount": 45
    }
  },
  "likes": {
    "car_1": {
      "user1": true,
      "user2": true
    },
    "car_2": {
      "user1": true
    }
  },
  "userLikes": {
    "user1": {
      "car_1": true,
      "car_2": true
    },
    "user2": {
      "car_1": true
    }
  }
}

写操作注意点：当用户触发点赞/取消点赞操作时，用实时数据库的多路径更新一次性同步修改三个节点的数据，避免出现数据不一致。可以用官方提供的原子计数接口，避免并发操作导致的点赞数计算错误，示例代码：

import { getDatabase, ref, update, ServerValue } from "firebase/database";

const db = getDatabase();
// 用户给car_1点赞时的批量更新逻辑
const updates = {};
updates[`/likes/car_1/user1`] = true;
updates[`/userLikes/user1/car_1`] = true;
updates[`/cars/car_1/likeCount`] = ServerValue.increment(1);

await update(ref(db), updates);

因为已经提前把用户和车的关联关系存在userLikes节点下，查询完全不需要遍历全库，分两步就能完成：

1. 拉取对应用户的点赞车ID列表
   直接定位到userLikes/{userId}节点拉取数据，拿到所有存在的车ID，全程只需要读取该用户名下的一小部分数据，流量成本极低。示例代码：

import { getDatabase, ref, child, get } from "firebase/database";

const dbRef = ref(getDatabase());
const userLikeRef = child(dbRef, `userLikes/user1`);
const userLikeSnapshot = await get(userLikeRef);

if (!userLikeSnapshot.exists()) return [];
// 提取所有点赞的车ID数组
const likedCarIds = Object.keys(userLikeSnapshot.val());

2. 批量拉取对应车辆的属性
   拿到车ID列表后，并发请求每个ID对应的车辆数据，用Promise.all等待所有请求完成后整合结果即可。如果用户点赞的车辆数量很多（比如超过100个），可以提前在userLikes节点冗余存储车辆的标题、缩略图等列表页需要的核心字段，第二步就不需要单独拉取cars节点，进一步减少请求次数，提升列表加载速度。

很多人看完Firebase的多对多关系文档还是不会落地，核心是习惯了关系型数据库单份关联关系的设计思路，觉得双向存关系是冗余浪费。但实时数据库的存储成本远低于流量和查询的成本，提前把两个查询方向的关联关系都存好，是最高效的实现方式，不需要等查询的时候再临时做关联。

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