Структура базы данных для отправки сообщений между зарегистрированными клиентами / гостями и агентами компании
TL; DR
Система обмена сообщениями в стиле Facebook с Laravel / MySQL, где гости также могут отправлять сообщения агентам компании. Агенты компании могут начать беседу с зарегистрированными клиентами.
Полная информация
Я пытаюсь создать систему, которая позволяет зарегистрированному клиенту / гостю отправлять сообщения агентам компании и наоборот, но я застрял во взаимоотношениях между отправителем / получателем сообщения и самим сообщением.
Это список требований к этой системе (я уже рассмотрел почти все пункты):
- Разрешите как зарегистрированным клиентам, так и гостям отправлять сообщения. Клиенты и гости могут отправлять сообщения только в отделы компании. Это означает, что клиенты не могут отправлять сообщения другим клиентам.
- Создавая сообщение, создатель должен указать, какой тип сообщения создается, выбрав нужный вариант из списка категорий.
- Каждая категория должна быть получена «ролью» (так, сообщения, связанные с выставлением счетов, будут получены финансовым отделом, сообщения поддержки будут получены службой поддержки клиентов и т. д.).
- Сообщения могут поступать из 1) контактной формы, доступной на странице контактов веб-сайта, где запрашиваются имя, фамилия, адрес электронной почты, номер телефона, тема и сообщение; и 2) электронные письма, отправленные пользователями (тогда система получит электронные письма через веб-перехватчик и сохранит их должным образом).
- Все отделы могут связаться с любым пользователем (зарегистрированным или нет) в любое время. Это означает, что они могут отвечать на сообщения, но также могут «начинать» беседу (пример: сообщение с просьбой подтвердить / обновить детали).
Вот что у меня сейчас есть:
Это охватывает почти все, кроме отношений пользователей / гостевых сообщений.
Каждое сообщение создается кем-то (зарегистрированным клиентом, зарегистрированным агентом компании или гостем) и направляется кому-то (зарегистрированному клиенту в отдел, гостю в отдел, зарегистрированному агенту компании зарегистрированному клиенту или зарегистрированному агенту компании, отвечающему гостю) .
Мой текущий подход заключается в использовании двух таблиц: Guest и User. Таблица User будет содержать как клиентов, так и агентов (это просто, мне просто нужно назначить правильную роль). Это означает, что мне нужно сохранить в таблице Message sender_type (гость или пользователь), sender_id (идентификатор), Receiver_type (гость или пользователь) и Receiver_id. Но, например, когда клиенту Customer1 нужно отправить сообщение в отдел биллинга, я не знаю, какой агент ответит на это сообщение. Означает ли это, что я должен хранить «ноль» в полях получателя? Это может привести к появлению множества строк с нулевыми столбцами.
заранее спасибо
Ответы 1
Наличие двух отдельных таблиц - это один подход. Вы хотели бы убедиться, что данный гостевой пользователь все еще может получить доступ к своей беседе после отправки сообщения, поэтому вам нужно сгенерировать идентификатор гостевого пользователя и, в идеале, иметь другую аутентификацию для доступа к этим сообщениям (безопасно).
Что касается фактического пользователя, у меня была бы просто таблица с данными профиля пользователя, хранящимися в ней с «типом пользователя» в качестве типа вашего зарегистрированного клиента (C) или зарегистрированного агента компании (A).
Хотя вы можете просто поместить это в одну «пользовательскую» таблицу, сгенерировав идентификатор гостевого профиля и аутентификацию вне MySQL в PHP, а затем вставив это в свою пользовательскую таблицу. Это значительно упростило бы задачу запроса данных и индексации.
Любой из них будет работать, но я лично выберу второй вариант.
Не беспокойся, @TJistooshort! Да, он добавит больше строк в "пользовательскую" таблицу, но более эффективно хранить их в одной таблице, а не в двух. По крайней мере, я бы добавил user_type в этот список столбцов.
Большое спасибо за ответ @LovelyBanter! Приведет ли этот второй вариант к увеличению «пользовательской» таблицы? В настоящее время моя таблица пользователей очень проста: идентификатор, имя, адрес электронной почты, пароль, статус, created_at, updated_at.