@WAYNEDEV

Создания уникального чата: sql, node, socket.io?

Всем привет!

Хочу узнать ваше мнение о организации создания приватного чата. В этом деле без опыта, хотелось бы узнать инфу от более опытных.

Правила для приватного чата: Есть роль А И B. Только роль A может начать чат с ролью B, в другом случае чата быть не должно. Чат может содержать только 2х лиц.

Со стороны sql:
1 - Если роль А начал чат с B, то в таблице chat создаются колонки id, user_id, second_user_id
2 - Вся переписка будет хранится в таблице chat_messages, где есть колонки chat_id, user_id, message

Со стороны node:
1 - перед созданием чата делать проверку, что только роль A создает чат с B
2 - получать id чата и создать/перейти комнату с этим id в socket.io

Со стороны socket:
1 - принимать все сообщения в конкретной комнате и отправлять всё в базу

Пойдет ли такая структура? Или есть более лучший вариант?

Буду очень благодарен за любую помощь!
  • Вопрос задан
  • 359 просмотров
Решения вопроса 1
@alexalexes
Есть роль А И B. Только роль A может начать чат с ролью B

Роли у пользователей заданы на уровне учетной записи и не меняются от чата к чату или определяются в момент создания чата?
То есть при создании чата будут определена роль администратора (создателя) которая будет более привилегирована, чем тот, кому он пишет?
Чат может содержать только 2х лиц

Вы очень оптимистичны, выставляя такое ограничение. В следующей итерации разработки вам захочется сделать функционал группового чата. Тогда наличие колонок user_id, second_user_id вам встанет боком.
В таблицу chat лучше добавить такие колонки:
id - идент. чата
date_create - дата создания
id_user_creator - кто создал чат
title - название чата (в этой итерации разработки можно не вставлять)
Для участников чата лучше предусмотреть таблицу chat_participant:
id - идент. участника
id_chat - идент. чата из таблицы chat
id_role - роль в чате (если она определяется в момент создания, для группового чата)
id_user - пользователь чата
id_last_read_message - идент. последнего прочитанного сообщения (самый простой вариант, как отмечать что прочитано, и потом определять, есть ли новые сообщения)
date_include - дата вступления в чат (для группового чата)
date_exclude - дата исключения из чата (для группового чата)
Для сообщений чата - таблица chat_message:
id - id сообщения
id_partic/id_user - автор сообщения (можно реализовать как по ключу от таблицы участника, так и по таблице пользователей)
date_create - дата создания сообщения
date_update - дата обновления сообщения (для продвинутого функционала редактирования сообщений)
date_delete - дата удаления сообщения (для продвинутого функционала редактирования сообщений)
text_message - текст сообщения
Если совсем хотите быть продвинуты в функционале редактирования сообщений, то вы захотите хранить историю изменения сообщений в таблице chat_message_history:
id - идент. истории
id_next - указатель на следующую запись истории
id_message - идент. сообщения
date_change - дата изменения сообщения
id_user/id_partic - кто изменил
text_message - состояние текста сообщения
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Zoominger
@Zoominger
System Integrator
Ну на первый взгляд проблем нет, особенно, если вы намеренно опустили часть с регистрацией пользователей и назначением им ролей. Ну и я бы на каждую запись в chat_messages накинул колонку "access" с доступом только указанным ролям (в которые могут входить роли A и B и ещё бы добавил роль "FBI" для доступа к чату администратора системы), а то у вас так кто угодно к перепиське доступ получит. Ну и, конечно, возможность удаления сообщений (хотя я бы не удалял, а просто менял права доступа к записи на "только FBI", как это реализовано, например, в ВК и ТГ).

Осталось самое простое и быстрое - реализация.
Ответ написан
@4ngry_biscuit
А сколько стоит создание такого чата? Я пытался задать вопрос сам но моедратор не разрешил. Я реально не могу в инете найти среднюю стоимость...
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы