用于社交应用程序的NoSQL数据库结构（喜欢只被共同的朋友可见）
如果我只和乔是朋友，我就看不出鲍勃是什么样子的。
我应该如何构造我的数据？我计划为每个用户创建PostFeeds：
— PostFeed (collection)
— Uid (document)
— Posts (collection)
— Likes (collection)
如果我写了一篇新的帖子，它会被添加到我所有朋友的帖子提要中。如果我有1000个朋友，该帖子将被添加到1000个提要。
共有1个答案
我有点想不写一个决定性的答案，但回到这个问题后，我倾向于不缩放。当然，你可以说Firebase可以跟上它，如果可以的话，你可以称赞Firebase，但这个数字似乎太高了，以至于不能忽视它可能不是资源的最佳利用。
让我们举这个例子：
如果我在该帖子的每个实例上存储每个帖子的每个like，我可以很容易地在500个like中只写一个，没有朋友检查。如果我对其中的每一个都进行了朋友检查，并且这500个中的每一个都是因为他们是唯一的用户而存在的，那么这就是500个唯一的朋友检查。
我认为，如果您考虑到规模，那么另一个选择是，是否可以以一种能够在运行时执行调用的方式存储数据，而不是存储所有这些数据？
或者从一开始就开始变小，你能在本地存储一个我是朋友的所有用户的列表，然后拉出一个喜欢一个帖子的所有用户的列表吗？
无论如何，如果您的示例符合代码的实际应用程序，我认为这是一个非常不典型的情况，会导致许多用户对每个帖子都看到0个或很少的“赞”。有点让你怀疑果汁是否值得榨。
-
问题内容： 实际上，我有2个表Friends表和users表，我想要达到的目的是通过检查另一个用户的朋友来获取我的共同朋友，并从users表中获取这些共同朋友的数据 表的朋友是这样建立的 然后表格数据看起来像这样 然后假设我是ID为2的用户，那么在该表中我有3个朋友-1、3和4。我要检索的是与用户1相同的朋友，他们也有3个朋友-2、3和4。并从表用户中检索2个共同的共同朋友3和4的数据 问题答案：
-
我希望基本上在我的应用程序内翻拍Kik。对于我在firebase聊天应用程序上看到的大多数指南，都有一个主要的消息节点，然后在该节点下面有一个扇出，每个用户都有引用主列表中消息的消息。 根据目前我的Firebase的布局方式，实现类似以下内容会更容易： 因此，当用户向对方发送消息时，我会更新发送者和用户下面的“聊天消息”节点。 有什么理由不这样做吗？我看到每个人都按照我描述的第一种方式进行，但我看
-
问题是，从性能上看，这些选项中的哪一个（显然，可能还有第三个我们没有考虑）是最好的。我认为第二种选择我看到了几个缺陷，但我不确定。就延迟和速度而言，遍历数组（如果添加了服务，或者由于用户首先使用了service2，然后使用了Service1)，遍历数组的次数会更多）比选项1要高得多。此外，一个用户在一个服务下，这意味着要遍历整个数组，寻找并消除它。我不知道你是专家，你有什么建议吗？所有这些都将上传
-
当用户导航到Likes或Comments屏幕时，他/她将分别看到用户指定帖子的Likes或Comments列表。 用这种结构能正确处理这两种情况吗？或者将评论和喜欢集合放在/posts/{userId}/userposts/{postId}/（也可以作为子集合）中会更好 Firestore可以同时执行“多个集合查询”吗？以便在我的“交互”屏幕中，我可以从按日期排序的不同集合中获取所需的数据 我很感
-
我正在尝试为一个简单的社交媒体概念创建一个简单的云Firestore数据库结构。 每个用户最多可以有一个可以随时更新的帖子（一个“最喜欢的”帖子除外）。用户“最喜欢的”版本的帖子被保存为一个单独的帖子，当用户在其当前版本的帖子上收到比最喜欢的版本更多的赞时，该帖子可以被更新。 friends子集合存储好友用户名，因此很容易按用户名创建该用户的好友列表。我假设我可以通过将朋友的documentID与
-
为了了解在朋友关系中使用Neo4J的优势，我在MySQL数据库上创建了一个Persons表（“Persons”，20900个数据集）： 和一张关系表（“友谊”，每个人有50到100个朋友）： 因此，大约有120万人的关系。 现在我想查看id=1的人的朋友的朋友的朋友的朋友，因此我创建了一个如下查询： 用户ID 1的查询用了大约30秒 在Neo4J中，我为每个人创建了一个节点（20900个节点）和一