Как структурировать базу данных Firestore в приложении чата? - PullRequest
0 голосов
/ 02 января 2019

Самый простой способ хранения сообщений чата, вероятно, таков:

message:
 -message1 {
   "user1"
   "user2"
   "message"
   "date"
  }
 -message2
 -message3

Когда приложение увеличивается в размере (много сообщений), а операции с базой данных выполняются с помощью .whereEqualTo, есть ли недостатки?структурировать сообщения чата таким образом?Как в случае с базой данных, повторяющейся во всех сообщениях?

Поскольку, если есть проблемы с этим подходом, я видел, например, такой способ структурирования базы данных, который будет разделять сообщения в разных комнатах чата

chats: {
    -chat1 {
      "lastMessage"
      "timestamp"
      "users": {user1, user2}
    }
    -chat2
    -chat3
  }

messages: {
 -chat1 {
  "message"
  "date"
 }
}

Но в этом примере добавление нового сообщения потребовало бы от пользователя выполнения 2 операций записи, одной записи нового сообщения и одного обновления chat документа с новыми lastMessage и timestamp на стороне клиента, или создания облачной функции для обновленияchat документ с новыми значениями при добавлении нового сообщения.

Итак, допустим ли первый вариант или я должен пойти с чем-то вроде второго примера?

1 Ответ

0 голосов
/ 02 января 2019

То, что вы предложили в качестве первого варианта, близко к тому, как вы смоделировали бы это в базе данных отношений в tblMessages. Такой буквальный перевод редко является лучшим вариантом в базах данных NoSQL, поскольку у них очень разные компромиссы. Например, вы уже заметили, что вам нужно выполнить запрос к двум полям, чтобы получать сообщения между двумя пользователями.

При моделировании данных в базе данных NoSQL я обычно рекомендую моделировать в вашей базе данных то, что вы видите на экране. Поэтому, если ваше приложение чата имеет концепцию чатов (то есть постоянные чаты между определенными группами людей), я бы смоделировал их и в вашей базе данных.

В Cloud Firestore это означает, что у вас будет коллекция верхнего уровня с документом для каждой комнаты чата, а затем подколлекция под каждым таким документом с сообщениями для этой комнаты чата:

ChatRooms (collection)
  ChatRoom1 (document)
    Messages (collection)
      Message1_1 (document)
      Message1_2 (document)
  ChatRoom2 (document)
    Messages (collection)
      Message2_1 (document)
      Message2_2 (document)

В этой модели вам не нужно запрашивать показ сообщений в чате, а вместо этого можно просто загрузить (все) сообщения прямо из вложенной коллекции для этой комнаты. Преимущество также состоит в том, что вы разделяете комнаты, что означает, что записи могут масштабироваться намного лучше.

Обычно я рекомендую смоделировать идентификаторы документов чата после участников в комнате, чтобы вы могли легко восстановить идентификатор на основе участников. Но для этого есть более действительные варианты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...