То, что вы предложили в качестве первого варианта, близко к тому, как вы смоделировали бы это в базе данных отношений в 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)
В этой модели вам не нужно запрашивать показ сообщений в чате, а вместо этого можно просто загрузить (все) сообщения прямо из вложенной коллекции для этой комнаты. Преимущество также состоит в том, что вы разделяете комнаты, что означает, что записи могут масштабироваться намного лучше.
Обычно я рекомендую смоделировать идентификаторы документов чата после участников в комнате, чтобы вы могли легко восстановить идентификатор на основе участников. Но для этого есть более действительные варианты.