Структура таблиц: conversations (id) conversation_participiants (id, user_id) conversation_messages (id, conversation_participiant_id, conversation_id, content) users (id) Связи: Conversation

(id) HasMany ConversationMessage (conversation_id)
ConversationParticipiant (conversation_id) HasMany Conversation (id)
ConversationMessage (conversation_id) BelongsTo Conversation (id)
ConversationParticipiant (user_id) HasOne User (id)
User (id) HasMany ConversationParticipiant (user_id)

Таким образом ты получаешь сильные явно выстроенные связи.

Как с ними работать:
1. Получить список Conversation у User.
SELECT conversation_id FROM conversation_participiants WHERE user_id = ?
INNER JOIN conversations ON conversations.id = conversation_participiants.conversation_id

2. При переходе в диалог получить список сообщений (предполагается, что мы знаем conversations.id)
SELECT * FROM conversation_messages WHERE conversation_id = conversations.id

я сохранил, пока что сложно, попробую перенести в sequelize

Да тебе просто добавить моделей и таблиц в базу. Ну и связи немного изменить

кстати, есть пакет sequelize-auto-models, он вроде даже связи автоматом генерит, на основе внешних ключей из базы

А вот этого я не знаю. Я в жс с муськой не работал

21th
Я вроде свой способ придумал, может не такой хорош...

такой способ юзаем для эмейлов, где у нас переписка также как у тебя «dialog», единственная проблема может быть если нужно счетчик непрочитанных для юзера светить

классно будет если покажешь как лучше сделать

да я хз пока что как лучше) но это вариант вполне рабочий. т.е. сущность dialog/conversation хранит мета инфу о переписке юзеры, какое самое новое сообщение (чтобы в списке отображать последнее сообщение), какой статус (для каждого участника - прочитан/нет) а уже в списке сообщений привязка по dialogId но минус такого подхода - если у тебя в эмейлах рассылка, тогда чтобы придерживаться такой структуры, тебе нужно создавать копии сообщения для каждого диалога отправителя и также в поле «получатели» выборку тянуть через dialogId

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

да, я как раз про это говорил выше) в случае с noSQL (монга) - это просто делается) а вот с pgsql (если считать, что json у них уже шустрый), то достаточно json поле для meta добавить и его расширять

нет, не проще будет( ибо чтобы это все вычислить ему нужно на любой запрос (если это не дефолтный), запросить +1 запрос на то, чтобы подтянуть последнее сообщение

а ну да, точно, я просто не правильно представил у себя в голове как это должно выглядеть

)

МСМК

а что значит ConversationParticipiant?

участник конференции