Firestore视频存储结构设计与关联用户信息查询咨询

嘿，针对你在Firestore设计中遇到的两个问题，结合实际开发经验给你梳理下可行的方案：

问题1：独立Videos集合 vs 用户子集合？ #

推荐你选择独立的Videos集合，原因如下：

• 查询更灵活：你的场景是两个用户之间的视频，需要支持从任意一方的个人资料中查看关联视频。用独立集合的话，只需要执行一次查询：where("PersonAId", "==", currentUserId) 或 where("PersonBId", "==", currentUserId)，就能快速拿到当前用户参与的所有视频；如果用子集合，你得分别查询当前用户的子集合和所有关联用户的子集合，逻辑会复杂很多。
• 职责更清晰：User模型专注于用户核心资料，Videos集合专注于视频数据，符合单一职责原则，后续扩展视频的额外属性（比如时长、观看次数、评论）时，不用修改User的结构。
• 扩展性更强：如果以后需要做全局的视频统计、管理功能（比如后台查看所有视频），独立集合的结构会比分散的子集合方便太多。

当然子集合也不是完全没用——如果你的视频是严格属于单个用户的（比如用户的个人录制视频），子集合会更合适，但你的场景是双人视频，独立集合显然更适配。

问题2：如何高效获取另一方的姓名？ #

Firestore本身不支持SQL式的JOIN查询，但有两种实用的方案：

方案1：客户端并行查询（简单可靠） #

既然你已经拿到了当前用户的姓名，只需要从Video文档中提取出另一方的ID（比如如果当前用户是PersonAId，就取PersonBId），然后单独发起一次getDoc请求获取对方的profile文档。Firestore的客户端SDK会自动并行处理这些请求，性能上不会有太大问题，而且能保证拿到的姓名是最新的，不会出现数据不一致的情况。

示例代码（JavaScript）：

// 假设当前用户ID是currentUserId，已拿到video文档
const otherUserId = video.PersonAId === currentUserId ? video.PersonBId : video.PersonAId;
const otherUserDoc = await getDoc(doc(db, "profile", otherUserId));
const otherUserName = `${otherUserDoc.data().First name} ${otherUserDoc.data().Last Name}`;

方案2：冗余存储姓名（查询更高效） #

如果想避免额外的数据库调用，可以在Video文档中冗余存储双方的姓名字段（比如PersonAName、PersonBName），这样查询视频时直接就能拿到姓名。但要注意数据一致性：当用户修改自己的姓名时，需要同步更新所有关联的Video文档。

你可以用Cloud Functions来实现自动同步：监听profile集合的文档更新事件，当用户修改姓名时，查询所有包含该用户ID的Video文档，批量更新对应的姓名字段。这种方式牺牲了一点写入性能，但能极大提升读取效率，适合用户姓名不频繁修改的场景。

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