Как сделать диалоги как vk, с минимальной нагрузкой?
Добрый вечер, возник такой вопрос, как сделать диалоги, например, как в VK. Не нужно предлагать готовые скрипты, нужно просто подтолкнуть на мысль. В голову лезит создать таблицу с диалогами и вносить туда данные в json формате, но потом делать выборку будет сложно. Поэтому пока что тупик. Прошу ваших советов. Заранее спасибо)
Для атачей можно еще в таблицу messages добавить поле is_attachments, на случай если передаем файлы, ну и табличку messages_attachments с полями: message_id, file_name. Так например удобное будет выборку делать по всем атачам.
Артем: нужно еще таблицу добавить user_messages // user_id, message_id и при записи нового сообщения вставлять по строке для каждого участника диалога.
Зелим Бельтоев: тогда ты нарушишь вторую нормальную форму. Проще говоря, будет избыточность данных, то есть дублирование контента в поле message для каждого участника диалога.
Просто подумай, как бы ты в своем решении реализовал редактирование сообщения, которое уже сохранено в базе. Тебе придется обновлять кучу строк, вместо одной.
xfg: ты серьезно? Если добавить user_id, то будет дублирование и отсутствие возможности редактирования?
Пересмотри с утра, в моем варианте нет ни дублирования, ни отсутствия возможности редактирования + одним запросом можно получить сообщение, а не городить inner join-ы или подзапросы, чтобы связать сообщение с пользователем
xfg: все-таки понял твою мысль, но мы говорим о разном: я о том, что нужно хранить автора сообщения, а ты - о том, что у каждого пользователя должна быть своя цепочка диалога, из которой он может удалять не нужные ему сообщения.
Вопрос на засыпку: как ты хотел реализовать редактирование своего сообщения, если при добавлении оно не привязывается к тебе? =)
Зелим Бельтоев: ну я про редактирование как пример написал, а так да, нужно еще id автора сообщения хранить, чтобы только он мог редактировать. Да верно, у каждого своя цепочка диалога.
В фейсбуке френдлента похожим образом работает. Проблема аналогичная, аккумулировать посты от всех друзей. Только раскладывается пост по всем френдлентам друзей в фоне, так как друзей может быть десятки тысяч и соответственно если делать это в реалтайме, то создание нового поста может сильно тормозить.
xfg: все равно по-моему глупо хранить копии сообщения, хотите, чтоб каждый пользователь мог по отдельности удалять сообщения? не вопрос! Добавьте еще одно поле deleted_by_user (int) , удалил один из пользователей - установили там его id, удалил второй пользователь - проверяем пустое ли это поле, если пустое, значит этот все же первый удалил и устанавливаем туда его id, если не пустой, значит сообщение можно полностью удалить .
а если в беседе несколько участников, то вот тогда придется новую таблицу завести, что-то типа
deleted_messages | user_id message_id deleted_at(тоже думаю пригодится)
IceJOKER: никаких копий нет, все данные во второй нормальной форме. Здесь очевидная связь многие ко многим. Один пользователь может иметь много сообщений и одно сообщение может принадлежать многим пользователям. Следовательно, для такой связи нужна доп. таблица. У вас все тоже самое с таблицей dialog_users, отношение M:M между диалогами и юзерами. Есть у вас в таблице dialog_users какие-то копии? Нет. Так с чего вы вдруг взяли что в таблице user_messages они будут? Эта точно такая же связующая таблица, только между двумя другими сущностями (messages <-> users).
Одна таблица с сообщениями, в которой следующий минимум:
id, user_from, user_to, is_new, message, hide_on_user_from,hide_on_user_to,created_at
В гугле есть примеры запросов к такой таблице чтобы вытащить сами диалоги пользователя, ну а непосредственно сам диалог реализовать будет не так сложно
evgenybuckharev: а вот как впервом ответе, по крайней мере у меня один в один реализация. Но там проблема с удалением конкретного сообщения, но так как у меня удаляется полностью диалог, мне было достаточно в табличке dialogs_users использовать поле deleted_at, и там уже делать выборку из таблицы messages вида select * from messages where dialog_id = 1 and created_at >= dialogs_users.deleted_at
Артем: По мне с одной таблицей куда проще, я также реализовывал систему сообщений, по началу рассматривал вариант с несколькими таблицами, потом всё таки решил сделать всё на одной, и не раз не пожалел, а в плане вывода диалогов пользователя, допустим на странице диалогов, то достаточно выбрать самые новые сообщения из каждого диалога, и на основе их строить непосредственно вывод, делается это один запросом, и не сказать что он нагруженные, а плане пользования такой таблице все намного проще, заносишь сообщения, удаляешь, никаких сложностей нет
evgenybuckharev: есть один убийственный для этого метода аргумент, включить более чем 2 пользователей в диалог. И так же всё-таки будет быстрее работать с таблицей где только численные значения. Данных меньше при тоже сортировке нужно считывать с диска. Опять же у нас есть поиск по сообщениях, и при таком подходе без группировке не обойтись, ну или нужно будет делать вложенные запросы к таблицы типа limit 1.
Артем: насколько я знаю, в highload-ах денормализируют БД, добавляя дополнительные таблицы (например, в ВК - это таблица с последними сообщениями в каждом диалоге, чтобы, когда пользователь зайдет на страницу сообщений, можно было одним запросом вернуть список диалогов, а не делать запрос на диалоги + запрос на поиск последний сообщений). Я к тому, чтобы взяли на заметку и такую схему
dialog
---------
id
users (в json формате храним всех юзеров что в этом диалоге)
userMessage
----------
userId
dialogId
message
При отправке тупо добавляем по сообщению всем участникам диалога
к примеру если стандартный диалог (вы и друг) то любое сообщение необходимо добавить в бд дважды (вам и другу)
По сути отправляем каждому юзеру это сообщение
UPD.
для юзер листа создаём таблицу в которой в формате json храним все диалоги в которых участвует юзер
