Как структурировать сообщения NoSQL для получения непрочитанных по 1 запросу?

Question

Скажем, у меня есть структура NoSQL следующим образом:

messages  
  chat_id (known)  
    message_id (generated automatically)  
      {author, timestamp, content}

У меня также есть ветка users/, где я вижу последние входы обоих пользователей.
Я хочу получить количество непрочитанных сообщений для данного пользователя по 1 запросу.

Как бы вы реализовали такую ​​задачу?

Answer 1

При условии, что вы используете идентификаторы пользователя Firebase Authentication, uid, которые предоставляют согласованный uid для пользователя на всех устройствах, установка идентификаторов сообщений для документа /users/$uid - это путь.

Теперь все, что вам нужно сделать, это прослушать документ /users/$user с. onSnapshot(). Как только клиент выполнит действие, чтобы прочитать сообщение в снимке, просто удалите этот идентификатор сообщения из узла users/$uid.

То, как вы храните идентификаторы сообщений в users/$uid (userDocument), зависит от вас - может быть массивом или вложенным объектом, может даже быть возможно хранить идентификаторы сообщений индивидуально как тип reference при условии, что есть способ идентифицировать type == reference на стороне клиента (так что вы можете перебирать поля документа для поиска непрочитанных сообщений в вашем снимке в реальном времени).

Преимущество этого заключается в том, что вы упрощаете свой код / ​​систему. Позвольте Firebase отправлять вам обновления (новые непрочитанные сообщения) по мере их поступления.

Answer 2

Эта проблема состоит из двух частей:

1. Подсчет количества сообщений
2. Отслеживание прочитанного пользователем

Подсчет количества сообщений

Если вы используете базу данных Firebase Realtime или Cloud Firestore, есть два типичных подхода к подсчету:

1. Загрузить непрочитанные сообщения и сосчитать их на стороне клиента.
2. Храните счетчик сообщений в базе данных и обновляйте его каждый раз, когда вы читаете / пишете сообщение.

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

В этот момент вы переключитесь на , сохраняя счетчик в базе данных и обновляя его при каждой операции записи / удаления. Это дублирует данные, поэтому разработчики, имеющие опыт работы с реляционными базами данных, обычно сталкиваются с такими проблемами. Но это самый распространенный подход.

Вы можете обновить счетчик на стороне клиента или использовать подход на стороне сервера, такой как этот пример поддержки счетчиков в облачных функциях .

Отслеживание прочитанного пользователем

Чтобы узнать, сколько непрочитанных сообщений имеет пользователь, вам нужно знать, что пользователь уже прочитал. Здесь снова есть два общих подхода:

1. Отслеживание каждого отдельного сообщения, прочитанного пользователем.
2. Отслеживание идентификатора самого последнего сообщения, прочитанного пользователем.

Отслеживание отдельных сообщений звучит наиболее правильно, поэтому я вижу, что это делается много. Я также вижу, что разработчики борются с этим, так как это требует большого бухгалтерского учета. Это определенно возможно, но я бы рекомендовал начать с более простого подхода ...

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

Скажите, что я отслеживаю метку времени последнего прочитанного вами сообщения, и оно 1535725374298. Теперь я могу запросить в чате только те сообщения, которые были новее:

firebase.database()
  .ref("chat")
  .child(chatId)
  .orderByChild("timestamp")
  .startAt(1535725374298)