代码之家 › 专栏 › 技术社区 › Sebastijan DumanÄiÄ

Firestore:文档的版本历史记录

data-modeling google-cloud-firestore firebase

1

Sebastijan DumanÄiÄ · 技术社区 · 7 年前

我正在寻找一种适当的方法来构造Firestore数据库,以处理单个集合中文档的多个版本历史记录。

例如:我有一个名为其中有多个文件历史比如谷歌文档上的变化。

collections: offers
 - documents: offer1, (offer2, offer3, ...)
     - fields populated with latest version of the offer content
     - nested collection named history
         - nested documents for each version (v1, v2, v3), which in turn have fields specifing state of each field in that version.

这似乎有点过于复杂,因为我有最新的状态,而不是历史的嵌套集合。在平面结构中,数组中的最新项是最新状态,或者类似的东西。

此外,历史状态是在点击按钮时生成的,所以我不需要在历史中保存所有可能的更改,只需要在用户保存时进行快照。

我想使用Firebase作为我的数据库,因为我还需要其他一些东西,所以我现在不考虑不同的解决方案。

谢谢

编辑:根据亚历克斯的回答,这是我对这个问题的另一种看法。

Firestore-root
   |
   --- offers (collection)
        |
        --- offerID (document)
        |   (with fields populated )
        |        |
        |        --- history (collection) //last edited timestamp
        |            |
        |            --- historyId
        |            --- historyId
        |
         --- offerID (document)
            (with fields populated with latest changes)
                 |
                 --- history (collection) //last edited timestamp
                     |
                     --- historyId
                     --- historyId

offers 收集并获取报价数组以及最新状态,因为它与集合本身处于同一级别。然后,如果我需要来自历史状态的特定内容,我可以查询特定报价的历史集合并获取其历史状态。这有意义吗?

我不确定反规范化,因为这似乎解决了我的问题,避免了复杂性。

同样,要求是: -能够获取最新状态的所有报价(works)

我错过什么了吗?

1 回复 | 直到 7 年前

1

10

Alex Mamo 7 年前

只有从运行查询所针对的集合中获取项。Firestore不支持跨不同集合的查询。因此,您无法在单个查询中获得一个文档以及托管在该文档集合下的相应历史版本。

Firestore-root
   |
   --- offerId (collection)
        |
        --- offerHistoryId (document)
        |        |
        |        --- //Offer details
        |
        --- offerHistoryId (document)
                 |
                 --- //Offer details

如果要显示报价的所有历史版本,则需要一个查询。因此,您只需要在上附加一个侦听器 offerId 一次性收集并获取所有报价对象(文档)。

但是,如果您只想获取最新版本的报价,那么应该在每个报价对象下添加一个 timestamp limit(1)

根据你的评论:

我需要一份所有报价的最新数据列表

offers 它将保存您提供的所有最新版本。您的新收藏应如下所示:

Firestore-root
   |
   --- offers (collection)
        |
        --- offerHistoryId (document)
        |        |
        |        --- date: //last edited timestamp
        |        |
        |        --- //Offer details
        |
        --- offerHistoryId (document)
                 |
                 --- date: //last edited timestamp
                 |
                 --- //Offer details

这种做法被称为 denormalization 这是Firebase的常见做法。如果您是NoQSL数据库的新手,我建议您观看此视频, Denormalization is normal with the Firebase Database 为了更好的理解。它适用于Firebase实时数据库,但同样的规则适用于云Firestore。

另外,在复制数据时,有一件事需要记住。与添加数据的方式相同,您需要对其进行维护。换句话说,如果你想更新/删除一个项目,你需要在它存在的每个地方进行。

在您的特定情况下,当您想要创建报价时,您需要将其添加到两个位置,一个是在 讨厌的 提供 收集创建新的报价历史记录版本后,您只需再执行一个操作。与前面一样,添加 offerHistoryId 在您的 讨厌的 相同的 提供

2

1

Satish Reddy 7 年前

提供 奥菲氏体 作为号码。

您可以有一个单独的根集合,用于提供的版本化文档(例如 ).
现在在上编写一个更新触发器云函数具有文档的after和before值的文档。
在执行文档更新之前,您可以编写之前以及时间戳和最新的历史ID。
将该报价的offerHistoryID增加1,并使用新值更新文档。

报盘交易 用于基于过滤器的历史事务。通过这种方式,您可以保持根集合更干净。