替代嵌套文档中的修复-寻找最佳实践？

Question

我对基于修复的项目的结构有些担心，因为直接嵌套文档似乎不是一种选择。

为了保持简单，假设我们有一个包含足球比赛数据的消防站DB。对于每一场比赛，都有一个球员阵容的文档，一个包含比赛事件列表的文档，一个包含匹配统计信息的文档等等。

由于统计、事件和行等内容是按不同的时间间隔更新的，从不同的API调用导入，并在消费应用程序的单独屏幕中使用，我认为将它们保存在单独的文档中是最明智的做法。

我现在使用的是这样的结构：

/app-data/match-lineup/matches/123456
/app-data/match-events/matches/123456
/app-data/match-statistics/matches/123456

然后我用这样的方式来形容：

      db.collection("app-data")
      .doc("match-lineups")
      .collection("matches")
      .doc(id);

但是，当我添加更多与匹配相关的不同文档时，我开始关注当前的结构是否是反模式。

我更喜欢这样的结构，我觉得这种结构非常优雅，类似于REST URL。

/matches/123456/lineup

但这不是一个选项，因为123456不能引用lineup文档。

解决办法可能是这样的

/matches/123456/attributes/lineup

有这样的参考资料

      db.collection("matches")
      .doc(id);
      .collection("attributes")
      .doc("lineup")

这是最好的折衷方案，还是应该考虑其他选择？

Answer 1

在对数据库中的数据进行建模时，从来没有最佳和唯一的NoSQL解决方案。

IMHO，您的两种方法是完全有效的，因为每个集合中包含的数据将“在消费应用程序中的单独屏幕中使用”(也就是说，没有理由将所有数据集中在一个文档中，正如您提到的那样)。在查询效率方面，这两种方法是相似的。

然而，，，还有另一个您可能考虑的条件：(在编写本报告时)，您不能跨集合查询。当您需要跨匹配查询时，您可能会遇到一个用例，例如，在阵容中有一个特定球员的所有匹配，或者与eventType == "penalty"的所有匹配。在这种情况下，您应该使用方法1(即/app-data/match-lineup/matches/123456)，因为这种跨匹配的查询在方法2中是不可能的。