Приветствую.

Прошу комментариев.

Ситуация такая. В спокойном режиме поддерживаю слабо нагруженный сайт (100..200) активных пользователей в час пик.

Сайт построен на самописном движке, в котором имеется система сообщений.

Система сделана в лоб, и это создаёт ряд проблем в использовании и доработках.


Возник вопрос по созданию новой системы сообщений.


После обсуждения пришли к выводу, что новая система сообщений должна помимо всех стандартных возможностей позволять:
общаться более чем 2м пользователям, т.е. создавать "группы разговоров", (далее разговоры), позволять видеть статус просмотра сообщений адресатов, не должна нагружать сервер при построении списка разговоров.

Я прикинул примерную структуру таблиц, которая описана ниже:

Основная часть структуры состоит из 4х таблиц:

1. таблица разговоров t_talks.

talk_id
talk_name

2. таблица разговоров пользователя t_user_talks.
user_talk_id
user_id,
talk_id;

3. Таблица самих разговоров t_talk_messages.

message_id
user_id
talk_id
message - тело сообщения, текстовое
date - дата сообщений


4. Таблица ленты сообщений пользователя t_talk_tapes
talk_id
user_id
message_id



Как это должно работать:

В таблице t_talks находятся разговоры.
В t_user_talks связь между разговорами и пользователями, участниками разговора.
В t_talk_messages находится список сообщений разговора.
В таблице t_talk_tapes находятся ссылки для конкретного пользователя на сообщения разговора, их можно удалять, ставить флаг “просмотрено”, помечать и т.п.


Собственно вопрос такой.

На сколько “адекватна” данная структура?

miksoftА какие цели и задачи у этой "системы сообщений" ? Помочь в "поддерживании"?

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

сейчас все сообщения лежат в одной огромной таблице, их кол-во не очень большое, но уже за 5 миллионов перевалило.
формирование списка диалогов нагружает сервер, не смотря на все индексы и т.п., в таблице сообщений есть лишние поля.
и сейчас сделано так, что каждый пользователь имеет свою копию текста сообщения, что не правильно, и объём лишний занимает.

список диалогов на лету формируется с помощью group by, а так будет считывался готовый, и планируется чуть позже добавить возможность создания групповых чатов, т.е. общения в одном разговоре более чем 2м пользователям.

задачи простые: минимизировать нагрузку на сервер, добавить функционал.
цели: развитие сайта; обеспечение комфортного общение пользователей;
:)

MasterZiv1. таблица разговоров t_talks.

Поле user_talk_id лишнее, ненужно.

да, точно!

MasterZiv4. Таблица ленты сообщений пользователя t_talk_tapes
talk_id
user_id
message_id


Поле talk_id лишнее.

да, конечно, без единого пользователя разговор не имеет смысл.


а в остальном, такая структура имеет право на существование?

AkinaВы совершенно не проработали сам процесс. И схема должна быть намного сложнее.

меня интересует исключительно структура связанная с самими сообщениями.
artush Основная часть структуры состоит из 4х таблиц:


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

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

AkinaНапример, непонятно, как выполняется подключение пользователя к разговору. Захотел - влез? или нужно разрешение? или приглашение? а от кого? Должен ли подключившийся видеть разговор до его подключения? Надо ли отключаться от разговора? а если отключился - нужно ли приглашение для повторного подключения? Показывать ли в истории сообщения после отключения? А кто вообще создаёт разговор?

То есть вообще пока ясности даже близко нету, что именно создаётся и как будет работать. Какой сейчас смысл о структуре таблиц думать?

кстати, это в моём понимании не структуры, а скорее алгоритмов работы со структурой)

я это всё хорошо продумал. меня интересовала структура, касающаяся именно списка сообщений.
а так вопросы разрешения, авторизации и т.п. лягут на пхп скрипт, вопросы добавление в таблицы и добавления связанных объектов лягут на хранимые процедуры.

ничего навороченного не требуется. но для несложной системы сообщений, на мой взгляд, возможностей достаточно.

Акина, спасибо за подробный ответ, наверное вы правы, и я должен был подробней описать что я хотел.Хотя, я считал, что структура и моё описание структуры уже даёт ответ на логику работы.

Я же спросил “на сколько адекватно описанное”)

Список юзеров уже есть, это список пользователей сайта.
Что касается разговора, каждый разговор (чат) может быть подключен к произвольному кол-во юзеров.

Юзер должен иметь возможность удалять в своей ленте сообщений (t_talk_tapes) сообщения, при этом оно должно оставаться у других юзеров.

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

Т.е. при добавлении сообщения в разговор для каждого члена разговора создаётся запись в таблице t_talk_tapes и одно в t_talk_messages.

Сообщение о том, “юзер добавлен в разговр” должно быть текстовое, что ушёл, тоже текстовое, или это будет тип сообщения.

Нечто-то подобное есть в вк.

Целостность данных осуществляется средствами мускула.

зы:
Изначально я думал, что имеет смысл повторяющиеся сообщения в разных разговорах давать ссылками на таблицу t_talk_messages, но тогда придётся ещё добавлять поле хеша к тексту для быстрого поиска, но я прикинул, что размер хеша будет сопоставим по размеру с короткими сообщениями, котороый наиболее часто будут повтояряься, типа “Привет” и ещё придётся вести или счётчик ссылок или реализовывать “сбор мусора”. Но это так, мысли.