用于社交网络阻止配置文件的 Firebase Firestore 数据结构

Question

我正在使用 Firebase Firestore 构建一个社交网络，我对允许用户相互阻止的功能的数据结构有疑问。

目前我有一个名为 "blocking" 的集合，它有两个子集合，例如：

/blocking/{uid}/userBlocking/{targetUid} <-- the uids the user is blocking
/blocking/{uid}/userBlocked/{targetUid} <-- the uids the user is blocked by

当用户查看个人资料时，我会检查用户是否阻止了个人资料，或者个人资料是否被用户阻止了，这似乎没问题。

但是，对于每个 post，我还需要检查 post 作者是否 blocked/is 阻止以及对 post 的每条评论。在 25 个 post 的列表中，仅针对 post 对象额外调用了 50 次 Firestore，谁知道有多少次用于评论，这对于我希望不会出现的功能来说似乎不是最理想和过多的用了那么多

我可以将 blocked/blocking uid 作为数组存储在用户配置文件（用户集合文档）中，但这可能会变得笨拙并使配置文件文档膨胀。

你会怎么做？

Answer 1

我认为你所做的实际上是最好的情况。您已经正确地确定了可伸缩性和成本之间的权衡，这对于 NoSQL 类型的数据库来说是很常见的事情。如果你想要可扩展性，你将不得不接受成本。

您可以通过将客户端代码写入每个文档 get() 的 only check the local cache 来优化这一点，并且只定期刷新缓存，根据需要加载新文档。