Проектирование базы данных. Переписка между пользователями?

Question

[Uglik]

Здравствуйте.

Подскажите как реализовать подобную структуру:

Имеется таблица USERS (пользователи). Нужно реализовать переписку между ними. И выводить переписку с каждым юзером по отдельности.

Например: Пользователь с id_user 5 пишет пользователю с id_user 10, user 10 отвечает user 5. Пользователь с user_id 20 пишет пользователю с user_id 5 и тд

Как я понимаю мы создаем таблицу Messages (id, message, datetime, is_read) и таблицу связи между users и messages.

Не могу понять как индифицировать каждую переписку.

Answer 1

[sim3x]

id, id_user_from, id_user_to, message, datetime, is_read

Comments

[Uglik]

Не могу сообразить как тогда разделить сообщения по группам. Например пользователь 5 вел переписку с пользователе 3, 6,10,15. Получаеться нужно вывести каждую переписку по отдельности

[sim3x]

Uglik:
Для групповых чатов добавь поле с ид чата

[Uglik]

sim3x: тогда получаеться нужно создавать 2 таблицы ? Одну для хранения сообщений а другую для индификации чата. Может покажете на примере?

[sim3x]

Uglik:

chat_groups
id, name, ...

chat_message
id, id_user_from, id_user_to, id_chat_group, message, datetime, is_read

select * from chat_message where id_chat_group=123

Answer 2

[Вячеслав Онуфриюк]

Нет, вспомогательная таблица тут не нужна.

Если нужно, чтобы между юзерами могло проходить несколько разных переписок, стоит создать таблицу Conversations (id, initiator_id, date_started, etc ... ) - не для связи, а как самостоятельную сущность, а в таблицу Messages добавить три референса - sender_id, receiver_id и conversation_id.

Но если допускается, что сообщения между двумя юзерами - всегда одна переписка, то достаточно просто в Messages добавить sender_id и receiver_id. Это однозначно свяжет каждое сообщение с двумя юзерами.

А вот если нужна переписка сразу между несколькими юзерами, тогда уже нужна вспомогательная таблица ConversationMembers (user_id, conversation_id), а из Messages нужно убрать receiver_id - сообщение и так будет связано с перепиской, и все ConversationMember'ы смогут его получить.

Comments

[Uglik]

Нужно вот что. В таблице User есть group (например: парикмахер и клиент). Клиент авторизуется на сайте и ему в профиле парикмахера появляться форма для свази (textarea). Одному парикмахеру может написать много клиентов. И нужно разделить это по каналам переписки. Парикмахер заходит в свой аккаунт в раздел сообщений и видит что ему написал клиент Артем, Саша, Дима. Кликнув на клиента ему открывается канал переписки с одной стороны сообщения клиента с другой стороны сообщения парикмахера. И так для каждого клиента свой канал. Между 2 юзерами будет всего одна переписка.

Как я понимаю создаем таблице messages (id, sender_id, receiver_id, message, date time, is_read ) и таблица channel () и что должна содержать она ?

[Freeman]

Таблица channel не нужна. Sender_id -- и есть channel, если переписка одна.

[Вячеслав Онуфриюк]

Uglik: да, в таком случае таблица channel не нужна. sender_id в messages идентифицирует отправителя, а receiver_id - получателя. Соответственно, чтобы получить переписку между двумя юзерами, нужно сделать "select * from messages where sender_id in ( 1, 2 ) and receiver_id in ( 1, 2 ) order by time" где 1 и 2 - id переписывающихся юзеров.

[Uglik]

Вячеслав Онуфриюк: а если у каждого пользователя несколько переписок с разными пользователями ? 2-4, 2-8, 2-15 и каждую нужно выводить отдельно в новом окне. А на главной просто выводить по очереди список пользователей с которыми общаешься

[Вячеслав Онуфриюк]

Uglik: в первом случае сработает то, что я написал в прошлом сообщении. Нужно просто использовать id юзеров, между которыми велась переписка, чтобы получить эту переписку. А чтобы вывести список пользователей, с которыми велась переписка, можно сделать примерно так: "select receiver_id as id from messages where sender_id = 1 union select sender_id from messages where receiver_id = 1", где 1 - id пользователя, для которого нужно получить список. Только тут синтаксис может быть разный для разных субд. Здесь я написал для postgres.