Javascript 有没有办法在firebase中提出更少的请求？

实际上，我的firestore系列如下所示：

user :
    |-> 0000 (uid)
        |-> avatar : 'url'
        |-> name : 'josh'
    |-> 1111
        |-> avatar : 'url'
        |-> name : 'steve'
    [...]

follow :
    |-> 0000
        |-> 1111 : true
        |-> 8888 : true
    [...]

message :
    |-> 0000
        |-> 8888
            |-> 1264978800 (timestamp)
                |-> message = "hello"
            |-> 1264978987 
                |-> message = "How are you"
    |-> 8888
        |-> 0000
            |-> 1264914253
                |-> message = "hey dude "
            |-> 1264975895 
                |-> message = "fine and you?"

如果我想获得0000和8888之间的个人资料和对话（以获取他们的头像为例），我需要：

看看他们的朋友

如果是，则获取0000的消息

获取8888的消息

获取0000个人资料

获取8888个人资料

如果我想要0000的所有对话列表，我需要执行以下操作：

检查所有用户以了解他们是否是朋友

对于每个朋友，获取个人资料

对于每个朋友，获取消息列表 这是一个非常简单的查询，看起来比mysql中的查询要重

有一种方法可以避免所有这些查询？我的数据库模式好吗

---

感谢您的帮助。

是时候考虑一下Firebase的NoSQL了。Firestore是一个实时数据库，性能非常重要。您的数据结构适用于SQL数据库，而不适用于NoSQL

以下是我为此用例提出的数据结构：

user :
    |-> 0000 :    //uid
        |-> id : '0000'
        |-> avatar : 'url'
        |-> name : 'josh'
        |-> follow : ['1111', '8888']    // Array of uid
    |-> 1111 :     //uid
        |-> id : '1111'
        |-> avatar : 'url'
        |-> name : 'steve'
        |-> follow : ['0000']    // Array of uid
    [...]

message :
    |-> AAAA    // message id
        |-> id : 'AAAA'
        |-> sender
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> receiver
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> time : 1264978800    // timestamp
        |-> message : "hello"
    |-> BBBB    // message id
        |-> id : 'BBBB'
        |-> sender
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> receiver
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> time : 1264978800    // timestamp
        |-> message : "hey dude"
    |-> CCCC    // message id
        |-> id : 'CCCC'
        |-> sender
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> receiver
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> time : 1264978800    // timestamp
        |-> message : "How are you"
    |-> DDDD    // message id
        |-> id : 'DDDD'
        |-> sender
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> receiver
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> time : 1264978800    // timestamp
        |-> message : "fine and you?"

上述结构是以NoSQL方式设计的。用户的配置文件被复制多次。数据的复制可以提高性能并降低带宽和CPU成本，而这比存储成本要高得多

好处：

• 每个用户都包含有关用户的所有信息
• 每条消息都包含有关消息的所有信息

现在，让我们看看您的用例：

如果我想获得0000和8888之间的个人资料和对话（以获取他们的头像为例），我需要：

看看他们的朋友

如果是，则获取0000的消息

获取8888的消息

获取0000个人资料

获取8888个人资料

查询

消息

发送方或

接收方

在

follow

中的位置

如果我想要0000的所有对话列表，我需要执行以下操作：

检查所有用户以了解他们是否是朋友

对于每个朋友，获取个人资料

对于每个朋友，获取消息列表

查询

消息

，其中

发送方

或

接收方

等于

'0000'

您可能遇到的其他用例：

• 好友列表，其中包含要列出的姓名和头像

您可以使用

follow

的映射数组来存储

uid

、

name

和

avatar

，如果您打算对其执行多个操作，甚至可以将follow作为子集合

• 用户更改名称或化身

与发送的消息数量相比，更改名称或化身的频率通常较低，并且可能不需要实时更改。如果需要更新所有消息，您可以创建一个云函数来批量更新所有消息

---

话虽如此，使用SQL或NoSQL显然是您的选择。两者都有各自的优点和缺点

谢谢，所以如果我理解的话，不管冗余，它都是最重要的？