Flutter中Firestore健身应用数据结构及查询效率优化咨询

我正在开发一款健身应用，目前设计的Firestore数据结构如下：

Workout

• difficulty（String）
• duration（String）
• exerciseSets（Firestore引用数组）

ExerciseSet

• repNumber（int）
• exercise（Firestore引用）

Exercise对象包含若干描述锻炼动作的字段（如动作名称、说明、配图路径等）。

当前获取完整Workout数据时，至少需要多轮Firestore调用：先获取Workout文档，再通过引用逐个获取对应的ExerciseSet（每个Workout通常包含多个），最后再通过每个ExerciseSet里的引用获取Exercise。因为ExerciseSet和Exercise会在多个Workout间共享，所以把它们存为独立文档。

获取并映射数据的代码如下：

for (var exerciseSet in fsWorkout.exerciseSets) {
  var fsExerciseSet = await _getFsExerciseSet(exerciseSet.ref);
  var set = ExerciseSet.fromFirstoreObject(fsExerciseSet);
  var fsExercise = await _getFsExercise(fsExerciseSet.exerciseRef.ref);
  set.exercise = Exercise.fromFirestoreObject(fsExercise);
  exerciseSets.add(set);
}
return Workout(fsWorkout.difficulty, fsWorkout.duration, exerciseSets);

我有几个疑问：

1. 这种数据结构设计是否合理？
2. 有没有更高效简便的实现方式来获取完整的Workout对象？
3. 使用Firestore引用相比直接存储文档ID字符串有什么优势？

补充说明：所有数据由我一次性添加完成，客户端仅需读取并获取包含ExerciseSet和Exercise的完整Workout对象。

一、数据结构设计合理性 #

你的设计整体是合理的，核心原因是Exercise和ExerciseSet的复用性：既然它们会被多个Workout共享，独立存储成文档能避免数据冗余，修改时只需要更新单个文档就能同步到所有关联的Workout，符合Firestore避免不必要重复数据的最佳实践。

唯一需要注意的点：如果后续出现同一个Exercise在不同Workout里需要搭配个性化备注、调整次数的场景，可能需要在Workout里嵌套部分ExerciseSet的个性化字段，但目前按你的需求来看，当前设计完全够用。

二、更高效的实现方式 #

当前代码的循环是串行调用，每个ExerciseSet和Exercise的获取都要依次等待完成，效率较低。可以改成并行批量获取来减少等待时间：

1. 批量获取所有ExerciseSet #

先收集Workout里的所有ExerciseSet引用，用Firestore的批量获取方法一次性拉取所有文档，替代逐个调用：

// 收集所有ExerciseSet的引用
final exerciseSetRefs = fsWorkout.exerciseSets.map((es) => es.ref).toList();
// 批量获取ExerciseSet文档
final fsExerciseSets = await FirebaseFirestore.instance.getAll(exerciseSetRefs);
// 转换为ExerciseSet模型
final exerciseSets = fsExerciseSets.map((doc) => ExerciseSet.fromFirstoreObject(doc)).toList();

2. 批量获取所有Exercise #

接着收集所有ExerciseSet里的Exercise引用，同样批量获取并建立映射：

// 收集所有Exercise的引用
final exerciseRefs = exerciseSets.map((set) => set.exerciseRef.ref).toList();
// 批量获取Exercise文档
final fsExercises = await FirebaseFirestore.instance.getAll(exerciseRefs);
// 建立引用到Exercise模型的映射表
final exerciseMap = Map.fromEntries(
  fsExercises.map((doc) => MapEntry(doc.reference, Exercise.fromFirestoreObject(doc)))
);
// 给每个ExerciseSet绑定对应的Exercise
exerciseSets.forEach((set) {
  set.exercise = exerciseMap[set.exerciseRef.ref];
});

3. 预聚合存储（适合一次性数据场景） #

因为你提到所有数据是一次性添加的，完全可以在数据初始化时主动创建WorkoutFull文档，把Workout、ExerciseSet、Exercise的完整数据嵌套进去。客户端直接读取这个文档就能拿到所有数据，彻底避免多轮调用。缺点是修改Exercise时需要同步更新所有关联的WorkoutFull文档，但对你的场景来说完全可行。

三、Firestore引用vs存储ID字符串的优势 #

1. 类型安全与直接访问：引用是Firestore原生类型，不需要手动拼接文档路径，直接调用ref.get()就能获取文档，避免拼写错误（比如集合名写错、ID格式错误）。
2. 写入时验证：Firestore会在写入时验证引用是否指向有效文档路径，存储ID字符串则无法提前验证，容易出现无效关联。
3. 查询便捷性：引用可直接用于关联查询（比如查所有关联某个Exercise的ExerciseSet），用ID的话需要先构建完整引用才能查询，步骤更繁琐。
4. 可读性更强：从数据结构上能直接看出是关联其他文档的引用，比单纯的字符串ID更直观，后续维护代码时更容易理解数据关系。

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