我们计划使用Google Firestore实施虚拟文件系统。
子集合的想法很好，因为它使我们可以根据文件夹层次结构对数据进行建模，例如：/folders/folderA/entities/folderB/entities/fileX
类似于实际的文件系统，我们希望处理跨文件夹移动，例如将嵌套的子文件夹folderB从父folderA移到父folderC。确实，通常情况下，我们要移动的文件夹本身可能包含自己的文件和文件夹的子集合，深度为任意K级。
This comment建议移动文档不会自动移动其关联的子集合。同样，deleting a document将放弃删除其基础子集合，而将其保留为孤立子。看来，将文件夹（及其实体）从一个父文件夹移动到另一个父文件夹的唯一方法是通过递归克隆+删除策略，如果子实体很大，可能很难可靠地进行交易。
另一种选择是放弃使用子集合，而是将所有文件夹存储在根目录下，而使用parent_id之类的文档字段来指向平面集合中的其他文档。此shouldn't impact querying speeds是由于Firestore的积极索引编制而建立的，但我们无法在本地复制此声明；也就是说，与在顶层存储所有内容相比，通过数据库中的文档总数增加，通过子集合进行查询的性能要高得多。可提供可重复使用的存储库here。请注意，该仓库使用的是本地模拟器实例，而不是实际的Firestore服务器。
任何建议都会很有帮助！