这是我们的问题：
我们正在建立一个员工目录。组织中的每个员工都可以搜索和查看同一组织中的所有其他员工。
我们目前正在考虑两种不同的方法来存储和管理员工：
接近A
维护每个组织下员工的子集合。在这个模型中，每个员工都将是自己的文档。
这种方法的好处是，我们可以利用firestore中子集合附带的所有功能。我们可以轻松地添加、更新和删除员工，而且随着集合的增长，我们不需要进行真正的更改。
这种方法的主要问题是，我们将有大量的阅读。如果我们以一家有1000名员工的公司为例，假设每个员工每天访问该目录5次，那么我们看到的是1,000 * 5 * 1,000 = 5,000,000 reads/day。对于一组每天只会改变几次的资源(假设员工流失(来说，这似乎太多了。
这个问题的明显解决方案似乎是缓存员工，但我不太确定如果不使用云函数来获取员工，我们如何做到这一点？
方法B
在每个组织文档上维护一个或多个员工阵列。在该模型中，所有员工都将存在于组织文档中。
这种方法的好处是，我们只需要读取一个文档就可以获取所有员工。这意味着获取藏品将更快、更便宜。
这种方法的主要问题是，随着员工阵列的规模增长，我们将不得不拆分组织文档。在员工人数超过5000人之前，这应该不会成为太大的问题，但看起来仍然很混乱。一旦数组被拆分，我们还需要管理每个员工属于哪个区块，从而使更新过于复杂。
说到更新，这种方法还使员工更新变得复杂，因为每次更新员工时，都必须重写整个数组。
有没有其他更好的方法来解决这个问题，或者我忽略了一些简单的解决方案？
提前谢谢。
方法B不会扩展，将来使用它会遇到麻烦。不推荐使用。此外，为了保护该文档，您将增加安全规则的复杂性，而且您还可能遇到在负载下写入文档的速率限制。我不建议这样做。
方法A是合乎逻辑的选择。它更干净，更有感觉。500万的阅读量仅为3美元，对于一家拥有1000名员工的公司来说，这只是微不足道的一笔钱。这比正确实现B的开发工作要少得多。如果您真的需要降低成本，那么就不要让每个人都一次性加载所有用户的文档。如果用户需要浏览列表，请改用分页。