Question

我正在尝试将一些使用DS的插件迁移到FS，我想知道数据结构。在我的DS中，我正在利用ancestors

因此顶层Kind是Users，其他Kinds则由Users的祖先组成。例如。种类Products的祖先是Key(Users,'UUID')。

在Firestore世界中，结构看起来像这样：

1. Users(Collections):
   {userID:...
   ...
   so on},
   {...},
   ...list of users

2. Products(Collections).User-1(Doc)
                           Subcollections{...list of product docs belonging to User1}
                        .User-2(Doc)
                           Subcollections{...list of product docs belonging to User2}

Users和Products顶级集合。

或

这种结构会更好：

+ Users (collection)
 * user_1 (document)
     - name: "Blah"
     - last: "Blah"
     + Product (subcollection)
         * product_1 (document)
             - title: "blah...."
             - vendor: "blah..."
             + Product_variants (subcollection)
                 * product_1 (document)
                     - name: "..."
                     - price: "..."
                 * product_2 (document)
                     - name: "..."
                     - price: "..."
         * product_2 (document)
             - title: "blah...."
             - vendor: "blah..."
             + Product_variants (subcollection)
                 * product_1 (document)
                     - name: "..."
                     - price: "..."
                 * product_2 (document)
                     - name: "..."
                     - price: "..."

有没有更好的方法来处理这种结构？从动作更新的角度来看，还要担心哪个更简单？我正在尝试了解update与query之间的权衡。例如，如果我的用户拥有超过100K个产品，并且在更新/删除/ ...上获取事件是该结构的缺点。

Answer 1

更新：自2019年5月起，Cloud Firestore现在支持collection group queries。

您现在可以以任何一种方式构造数据，并且仍然可以跨用户查询。

原始答案

如果我的理解正确，那么您是在询问扁平化收藏与子收藏之间的权衡。

就更新而言，没有任何实质性差异。要注意的一件事是，如果您的字段聚集在单个值的周围。例如，对于平面集合，如果产品具有更新时间字段，那么默认情况下，所有用户的更新次数限制为每秒500次。如果产品嵌套在用户内部，则每个用户每秒只能进行500次更新。但是，使用展平的集合，可以通过在更新时禁用默认的单字段索引并在（用户，更新时）创建复合索引来解决此问题。一旦执行此操作，它们就等效。

真正的区别在于可以进行查询。在现有的Firestore中，您只能在子集合树中查询。因此，例如，如果您要搜索特定标题或供应商的产品，则只能在单个用户内搜索。

如果展平集合以使产品成为顶级集合，则可以跨用户查询。

请注意，集合组查询是我们正在开发的一项功能，它将消除此限制。启动后，您将能够以任何一种方式来构造数据，并且仍然能够跨用户查询。

从数据存储到Firestore本机的数据模型

1 个答案: