带有子集合的 Cloud Firestore 架构

Question

我正在从 Firebase 实时数据库切换到 Cloud Firestore。我的数据库包含拥有存储的用户，每个存储都包含盒子。每个用户可以拥有多个包含 Box 的 Storage。每个 Storage 可以包含多个 Box。每个 Box 只能在一个 Storage 中。

在我的应用程序的主视图中，对于该特定用户，我需要列出所有存储以及每个存储中的框，如下所示：

Storage 1:
    Box 1
    Box 2
Storage 2:
    Box 3
    Box 4
    Box 5
...

然后，用户应该能够点击每个 Box 以查看内容和更多信息。

在 Firebase 实时数据库中，这可以通过每个用户一个请求来获得。现在有了 Firestore，我不确定如何创建最佳模型，因为我只能进行浅读。如果我使用子集合，我无法在一个请求中获得所有已连接 Box 的存储。然后，要获得所有盒子，我需要先执行一个请求以获取所有存储，然后为每个存储请求一个以获取盒子。

我对 Firestore 结构的想法是以下之一，但我不确定这是要走的路：

结构1：

使用两个单独的集合

Storages Collection
    storage_1:
        name: "Storage number one"
        user_id: "1"
    storage_2:
        name: "Storage number two"
        user_id: "1"

Boxes Collection
    box_1:
        storage_id: "1"
        user_id: "1"
    box_2:
        storage_id: "1"
        user_id: "1"

这个解决方案的问题是在为特定用户加载 Boxes 集合时如何获取存储的名称。然后我还需要在本地的每个存储下对它们进行排序。

我对结构的另一个想法是：

使用两个单独的集合和存储集合下的字典。

Storages Collection
    storage_1:
        name: "Storage number one"
        user_id: "1"
        boxes: [{ box_id: "1", name: "Box number 1" }, { box_id: "2", name: "Box number 2" }]
    storage_2:
        name: "Storage number two"
        user_id: "1"
        boxes: []

Boxes Collection
    box_1:
        storage_id: "1"
        user_id: "1"
    box_2:
        storage_id: "1"
        user_id: "1"

考虑到我上面解释的用户体验，这些结构中的任何一个是一个很好的解决方案，还是我错过了更好的方法？

Answer 1

以下是我可能会如何构建您的数据。

请注意，我将Storage 作为您的Users 集合下的子集合，但这完全是可选的。如果每个存储位只能由一个用户拥有，那么将其保留为子集合可能会很好，如下所示。但是，如果一个存储项目可以由多个用户拥有或者会经常切换用户，那么最好将其设置为顶级集合。

 + Users (collection)
     * user_a (document)
         - name: "Joe"
         - last_login: 20171130
         + Storage (subcollection)
             * storage_1 (document)
                 - name: "Living Room Storage"
                 - box_summary: {box_1: "Fancy box", box_2: "Plain box"}
                 + Boxes (subcollection)
                     * box_1 (document)
                         - name: "Fancy box"
                         - contents: "Gold coins and jewels"
                     * box_2 (document)
                         - name: "Plain box"
                         - contents: "Books"

我认为这里要注意的重要项目是storage 文档的box_summary 条目。这包含足够的信息，您可以在初始“查看我的存储”屏幕上为用户提供他们需要的信息，而无需发出一堆单独的请求，但它的缺点是您需要做一些额外的事情努力使这些数据保持同步。这种折衷对您来说是否值得取决于您认为用户添加或删除存储箱的频率，以及他们查看此“查看我的存储空间”屏幕的频率。