javascript - 有没有办法在 firebase 中减少请求？

Question

实际上我的 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 之间的个人资料和对话(例如获取他们的头像)，我需要:

1. 检查他们的 friend 是否有
2. 如果是，则获取0000的消息
3. 获取8888的消息
4. 获取 0000 个人资料
5. 获取 8888 个人资料

如果我想要0000的所有对话的列表，我需要这样做:

1. 检查所有用户以了解他们是否是好友
2. 获取每个 friend 的个人资料
3. 为每个 friend 获取消息列表。

这是非常简单的查询，例如，这看起来比 mysql 中的查询更繁重。

有办法不做所有这些查询吗？我的数据库模式好不好？

感谢您的帮助。

Answer 1

是时候考虑将 NoSQL 与 Firebase 结合使用了。 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 成本，而这些成本比存储成本高得多。

好处:

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

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

If I want to get the profile and the conversation between 0000 and 8888 (to get they avatar for exemple), I need to:

1. check if their friend
2. if yes, get messages of 0000
3. get messages of 8888
4. get 0000 profile
5. get 8888 profile

查询消息，其中发送者或接收者位于follow中。

If I want a list of all conversation of 0000, I need to do:

1. check all user to know if they're friend
2. for each friend, get profile
3. for each friend, get list of message.

查询消息，其中发送者或接收者等于'0000'

您可能会遇到的其他用例:

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

您可以使用follow的 map 数组来存储uid、name和avatar，甚至可以制作如果您打算对其执行多项操作，请作为子集合关注。

• 用户更改姓名或头像。

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

说了这么多，显然您可以选择使用 SQL 还是 NoSQL。两者各有优缺点