咨询在Firestore中复刻文件夹结构的最优文档存储方案

我正在开发一款文件管理应用，需要在Firestore里复刻文件夹结构（文件存储在Firebase Storage），目前在两种方案间纠结：

方案1：独立集合存储 #

创建两个独立集合：

• Folders集合：每个文档对应一个文件夹，包含字段：name（名称）、id（唯一标识）、owner（所有者ID）、parent（父文件夹ID）、childFolders[]（子文件夹ID数组）、childFiles[]（子文件ID数组）
• Files集合：每个文档对应一个文件，包含字段：name（名称）、owner（所有者ID）、parent（父文件夹ID）、downloadUrl（Firebase Storage下载链接）

方案2：嵌套集合存储 #

创建user集合，每个用户文档下嵌套层级化的文件夹和文件集合：
每个Folder文档包含name（名称）、id（唯一标识），同时在该文档下直接嵌套nestedFolderCollection（子文件夹子集合）和nestedFilesCollection（子文件子集合）

两种方案的优劣势对比 #

方案1

• 优点：
  • 结构扁平，全局查询效率高（比如查某个用户的所有文件、按类型筛选文件）
  • 文件夹和文件的增删改操作相互独立，逻辑简单，扩展性强（后续加权限、标签等字段直接在对应文档添加即可）
• 缺点：
  • 查询单个文件夹的内容时，需要先读取文件夹文档拿到子ID数组，再分别查询对应集合，多一次读操作
  • 遍历深层目录树时，需要多次递归查询，耗时较长

方案2

• 优点：
  • 目录结构直观，和本地文件夹逻辑一致，查询单个文件夹的所有子内容只需一次操作
• 缺点：
  • 全局查询极不友好（比如查用户所有文件），需要遍历所有嵌套集合，效率极低
  • Firestore嵌套集合最大支持100层，用户创建过深目录会触发限制
  • 批量操作（比如批量修改文件权限）难度大，需遍历所有层级的嵌套集合

选择建议 #

如果你的应用需要频繁进行跨目录全局操作，或者预计用户会创建深层目录，优先选方案1；如果用户主要在单目录内操作，且目录层级不会太深，方案2的直观性会更适合。

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