我需要在Firestore上建立多对多关系模型。要求摘要如下。
公司可以为一个项目雇用许多承包商。承包商可以在不同的时间为许多公司从事不同的项目。
对承包商或公司的数量没有限制，即应使用馆藏或子馆藏。
承包商应能够由公司查询；反之亦然，公司应该能够由承包商查询。例如，（1）承包商可以要求按项目和时间分类的他/她所工作的公司的清单，（2）公司可以要求按项目和承包商分类的一个月内为他们工作的所有承包商，并可能按周划分。
就公司而言，承包商可以更改状态，例如工作，完成。公司在项目生命周期内更改承包商的状态。此状态可以在查询中使用。
很明显，承包商不应访问其他承包商的信息。
在移动应用中，公司仅由一个用户代表。类似地，承包商仅由移动应用程序上的单个用户代表。
该移动应用程序内置于React Native中，据我所知，Firestore将其视为网络应用程序。
我正在考虑为每个公司/在每个公司下使用一个文档子集合。 每个文档代表一个项目。所有承包商的名称，他们的状态以及开始和结束时间都存储在此文档中。
同时，为每个承包商/在每个承包商下都有项目文件的子集副本。 每个重复的文档代表项目文档的部分副本（如上）。此重复文档存储公司名称以及项目的开始和结束时间。
a。每当建立关系时，例如签订合同后，将成批创建两个文档。
b。状态仅存在于文档的第一份副本上。
c。如果对几乎静态的数据进行任何罕见的更改，例如名称，电话，两个文件均已更新。
这种设计有意义吗？ 有任何关注，建议或更好的想法吗？ 如果您同意该设计，我希望收到您的来信，也许您可以在评论中写一些听起来不错的东西。
答案 0 :(得分：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集合中的两个文档。当您要显示一些仪表板时，这很方便。使用此单个集合，您可以显示公司，承包商的独立统计信息以及涉及公司和承包商的复杂统计信息。
希望这会有所帮助。