Firebase 社交应用的NoSQL数据库结构（只有共同的朋友才能看到喜欢）

使用firebase firestore构建react应用程序，用户可以在其中互为好友并对彼此的帖子进行投票。但是，您只能看到共同的朋友所做的投票

Ie:如果鲍勃喜欢乔的帖子

如果我是乔和鲍勃的朋友，我可以看到鲍勃的样子

如果我只是乔的朋友，我就看不到鲍勃那样的人

我应该如何构造我的数据？我计划为每个用户创建PostFeeds：

— PostFeed (collection)
     — Uid (document)
         — Posts (collection)
              — Likes (collection)

如果我写了一篇新文章，它会被添加到我所有朋友的帖子提要中。如果我有1000个朋友，这个帖子将被添加到1000个feed中

我在PostFeed中的每个帖子中存储每个帖子的赞。这样我们就不需要额外的查询就能得到喜欢的东西。因此，如果bob喜欢joes的帖子，那么joe朋友的帖子提要中的每个帖子都会添加类似的内容

Ie：如果乔喜欢鲍勃的帖子，而鲍勃有500个朋友。鲍勃的帖子在网上 500个朋友的帖子。Joe的like应该添加到所有的500个帖子中 每个PostFeed

但是，只有当我们是共同的朋友时，才能看到喜欢

Ie：如果bob喜欢joe的帖子，只有在以下情况下才会添加到用户提要中： 我们是共同的朋友。因此，请浏览joe的帖子，其中bob是 共同的朋友，并添加类似的帖子

这是可伸缩的吗？虽然大多数写操作都是在firebase函数中进行的，但写操作似乎非常昂贵。特别是如果用户喜欢，不喜欢，然后又喜欢。或者，如果我添加了一个新朋友，我需要添加新朋友在共同朋友的帖子上的所有投票

---

有没有更好的方法来处理这个问题呢？

我有点想不写一个决定性的答案，但回到问题上来后，我倾向于不进行缩放。当然，你可能会争辩说Firebase可以跟上它，如果可以的话，你会为Firebase赢得荣誉，但数字似乎太高了，不能忽视这可能不是资源的最佳利用

让我们举一个例子：

如果我在该帖子的每个实例上存储每个帖子的每个like，那么我 可能很容易达到500次写入，就像没有 朋友检查。如果我的朋友检查每一个，以及每500个 因为他们是唯一的用户而存在，那就是500唯一 朋友支票

如果我有500个追随者，我一天喜欢20件事，那就是10000件 我检查某人是否是我的朋友的次数是10000次 只是为了一个类似的目的向数据库写入数据。我希望你的预期超过20个 朋友们

我认为，如果您考虑的是构建规模，另一种选择是，数据的存储方式是否可以支持在运行时完成的调用，而不是存储所有这些数据

或者从一开始就比较小，你能在本地存储一个我的朋友列表，然后拉一个所有喜欢帖子的用户列表吗

---

值得一提的是，如果您的示例符合代码的实际应用，我确实认为这是一种非常非典型的情况，并且会导致许多用户在每个帖子中看到0或很少的“喜欢”。有点让你怀疑这些果汁是否值得榨取。

我想知道的是，如果你和我是共同的朋友，而我不是朋友的人是第一个喜欢你的帖子的人，我会认为你的帖子不受欢迎吗？你可以看一看，它可能会帮你想出一个主意。@DanFein是的，你会发现这篇文章没有什么好感，因为没有共同的朋友喜欢这篇文章。@AlexMamo谢谢，这正是我用来理解这一点的答案。但它并没有解释同样的反规范化是否应该应用于

upvots/likes

。因为它们的出现频率远远高于帖子，所以这可能会很快变得昂贵。特别是因为

喜欢的东西

只对共同的朋友可见，所以它们应该存储在每个用户的提要中的一个集合中，就像这样

userFeed/userId/postId/likes

@AlexMamo希望听到你关于在firestore中存储喜欢的想法（特别是在我的例子中，只有当你是共同的朋友时，喜欢才可见）。这是否有效：使用

uid

和

username

在本地存储所有好友。在firestore中，当用户喜欢一篇文章时，将其添加到

arrayLikes=[uid1、uid2等]

到该文章出现的所有提要中（不要检查他们是否是共同的朋友，只需保存所有喜欢的内容）。显示帖子时，将本地存储的两个好友数组与帖子对象中的

arrayLikes

进行比较。在显示15-30篇帖子时，这会不会太占用资源？或者将我的好友储存在本地Starray，其中包含我所有好友的

UID

。当我喜欢一篇博文时，我会循环浏览

FriendsStarray

，查询博文作者的好友列表，寻找共同的好友。如果他们是共同的朋友，那么在他们的订阅源中更新帖子。这就是我所做的，无论用户是否订阅了一长串帖子中的特定内容！我有一个单一的文件，每个特定类别的项目。每次加载提要时，我都会获取所有项目，查找唯一的类别，并提取这些类别的特定文档。然后，我只需再次遍历我的所有项目，并检查单个类别文档。目前看来效果不错。在将来的某个时候，如果一个类别的文档很大，我需要在每个类别中输入多个文档，但这比为每个项目打一个电话要好得多！