Question

目前正在开发具有聊天功能的应用，并且想知道我是否应该优先考虑最小化对数据库的调用或最小化数据库中的数据冗余。

示例数据库结构

对于用户部分：

users/
  active/
    $uid/ (Firebase Auth generated)
      username: string
      userPhotoUrl: string

对于聊天消息部分：

messages/
  chatRooms/
    $chatRoomId/
      dateCreated: timestamp
      title: string

  chatMessages/
    $chatRoomId/
      $messageId/
        createdAt: timestamp
        uid: string
        message: string

如数据库结构所示，如果我检索聊天对象（messageId），我只能检索createdAt，uid，message。这工作正常，但是，我还需要username和userPhotoUrl才能在客户端显示所需的数据。

方法：获取所需数据的流程是对数据库进行两次调用，一种是从中获取数据chatMessages节点上的users节点和另一个节点。

有两种情况我需要这些数据：

检索多条聊天消息（最初和每次用户决定查看较旧的消息时）。
新的聊天消息将保存到数据库中。

对于第一个场景，我要做的是首先检索chatMessages列表，一旦成功获取它们，我就需要调用DB来获取每条聊天消息的用户详细信息（username，userPhotoUrl） - 为了避免调用冗余，我在本地（在SharedPrefs中）保存每个用户详细信息，以便如果它已经存在，我会马上得到它。

优点：最大限度地减少Firebase数据库中的数据冗余，从而节省空间。
缺点：这涉及很多API调用，会增加实际显示聊天消息的时间。

使事情更简单的可能解决方法是为每条聊天消息设置username和userPhotoUrl。 E.g：

$messageId/
  createdAt: timestamp
  uid: string
  username: string
  userPhotoUrl: string
  message: string

优点：更容易检索，因为它只是一次通话。
缺点：数据冗余太多了。

对于第二种情况，每次检测到儿童被添加到$chatRoomId时，我都必须采用相同的方法。同样的利弊。

我知道NoSQL DB中的数据冗余很好，但对于包含大量消息的聊天应用程序，以及消息是可能包含冗余数据的数据，我认为这将是非常重的存储数据

问题是，我是否正确的目标是减少数据冗余，依次交易大量API调用？如果有人能提出一个我可能会错过的更好的方法，那就不胜感激了。

减少对Firebase的呼叫与减少数据冗余

0 个答案: