在 Firestore 上实现多对多关系

Question

我需要在 Firestore 上建模多对多关系。以下是要求的摘要。

1. 一家公司可以为一个项目雇佣多个承包商。一个承包商可以在不同的时间为许多公司从事不同的项目。

2. 不应限制承包商或公司的数量，即应使用集合或子集合。

3. 承包商应该能够被公司查询；反之亦然，公司应该能够通过承包商进行查询。例如，（1）承包商可能会要求按项目和时间排序的他/她工作的公司列表，以及（2）公司可以要求按项目和承包商排序的一个月内为他们工作的所有承包商，并且可能按周划分。

4. 就公司而言，承包商可以更改状态，例如工作，完成。公司在项目生命周期内更改承包商的状态。此状态可用于查询。

5. 显然，承包商不应访问其他承包商的信息。

6. 移动应用上只有一个用户代表一家公司。同样，承包商在移动应用上仅由一个用户代表。

7. 该移动应用是在 React Native 中构建的，（据我所知）Firestore 将其视为网络应用。

我正在考虑为每个公司/在每个公司下使用文件的子集合。 每个文档代表一个项目。所有承包商的姓名、状态以及开始和结束时间都存储在此文档中。

同时，每个承包商都有重复的项目文件子集。 这些重复文档中的每一个都代表项目文档的部分副本（上图）。该副本文件存储了公司名称以及项目的开始和结束时间。

一个。每当建立关系时，例如签订了合同，两个文件都是批量创建的。

b.状态仅存在于文档的第 1 份副本中。

c。如果对几乎静态的数据进行任何罕见的更改，例如。姓名，电话，两个文件都更新了。

这个设计有意义吗？ 有任何顾虑、建议、更好的想法吗？ 如果你同意这个设计，我很想听听你的意见，也许你可以在评论中写一些听起来不错的东西。

AskFirebase

Answer 1

在某些特殊情况下，您可以使用子集合，何时不使用子集合。

何时使用子集合：

1) 当您不想在文档中存储大量字段时。 Cloud Firestore 有 20,000 个字段限制。 （如果公司和承包商信息非常庞大，可以超过20,000个字段）

2) 更新父集合时是常见的操作。 Firestore 仅允许您以每秒 1 次写入的速率更新文档。 （如果公司和承包商信息经常被修改）

3) 当您想限制对文档特定字段的访问时。 （如果您想限制对公司承包商的访问，或者如果应该限制对承包商公司的访问。在这种情况下，将受限制的字段移动到另一个集合中的另一个文档也是一个好主意！）

何时不使用子集合：

1) 当你想同时查询集合和子集合时。 Firestore 查询很浅。所以查询父集合时不会查询子集合，所以必须单独查询。 （如果您有案例要在一个窗口中显示所有公司及其承包商）

2) 当您想在查看集合时显示子集合时。（当显示公司时，您可能希望显示其承包商。这里的阅读次数会增加，因为不是阅读一份文档，而是阅读一份文档文档及其子集合）

3) 当您想同时查询集合和子集合时。（您可以使用新发布的集合组查询来查询公司和承包商的共同点，例如工作领域或最低费率）

4) 如果您正在考虑查询单个数据，您应该将它们放在一个集合中。 （如果承包商的特定属性通常被公司查询或一个公司的详细信息被多个承包商查看）

我的建议：

Company 集合存储公司信息，可以根据其质量搜索哪些公司。

Contractors 集合使用相同的方法，因为我假设承包商将根据他们的属性被查询很多。

Projects 子集合以获取有关公司和承包商将合作的项目的信息。如果只有一家公司从事某个项目，则这可以是公司收藏下的子收藏。即使多个承包商将为一家公司从事一个项目，您也可以将承包商的 ID 存储在 Projects 集合中的数组中。这将帮助您避免每个 Company/Contractor 集合中的 Projects 部分子集合。

但是如果您需要查询项目的质量，最好将它们公开为单独的父集合。我把它留给你。

最后我建议一个新的集合Contracts，它可以用来存储Company、Contractor和Project之间的关系，以及所有可以进行复杂查询的信息。如果同一家公司和承包商有两个他们正在工作/合作的不同项目，那么它可以是Contracts 集合中的两个文档。当您想要显示一些仪表板时，这很方便。使用这个单一集合，您可以显示公司、承包商的单独统计数据以及涉及公司和承包商的复杂统计数据。

希望这会有所帮助。