Разработка личных сообщений

Question

Я разрабатываю новый сайт, и я должен делать личные сообщения для наших пользователей. Я уже делал это по другим проектам, но дизайн там просто не кажется правильным (у меня не может быть более двух человек, участвующих в сообщении, например). Так какой же «правильный» подход к этому? Я хотел бы предложить своим пользователям такую ​​же функциональность, как Facebook (опять же, я уже сделал это, но он чувствует себя грязным :)) Таким образом, система должна поддерживать 2 или более пользователей в сообщениях и потокоподобных сообщениях.

Я думал, и одно решение будет иметь две таблицы, как так:

pm_messages: идентификатор | pm_messages_id | user_id | название | содержание | date_time

pm_recipients: ID | pm_messages_id | user_id | has_seen | удалено

Я бы сохранил фактический контент в таблице «pm_messages», и я бы сохранил получателей (включая исходного отправителя) в таблице «pm_recipients».

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

Answer 1

Если может быть несколько получателей, и они могут отправлять ответные сообщения, вы больше имеете дело с каким-то чат-приложением. Вы можете хранить сеансы чата или беседы в отдельной таблице с соотношением 1-n между разговором и участником, а также соотношение 1-n между разговором и сообщением (таблицы, приведенные ниже). Но, в конце концов, это, конечно, зависит от вас. Для обычной отправки сообщений используется 1-n между сообщением и получателем, как вы используете.

table user: 
- id (pk) 
- name 

table conversation (one entry per "chat/messaging" session) 
- id (pk) 
- started_by_user_id 
- started_ts 

table conversation_participant (keeps track of all recipients) 
- id (pk) 
- conversation_id 
- user_id (refers to user.id) 

table message 
- id 
- conversation_id (refers to conversation.id) 
- sender (refers to user.id) 
- msg 

Answer 2

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

Одним из решений, которое я мог бы предложить, является использование одной таблицы, в которой хранится каждое сообщение, содержащее поле для идентификатора отправителя, и другое поле, которое представляет собой список идентификаторов получателей. Проблема, конечно же, заключается в том, как представить список идентификаторов с использованием одного из стандартных типов баз данных, учитывая, что обычно нет типа array/vector/list. Я бы предложил использовать тип VARBINARY (max), если он доступен, рассматривая его как битовый вектор (скажем, 4 байта на идентификатор получателя). Затем вы можете просто создать несколько функций, чтобы сделать очень простое побитное кодирование/декодирование в/из массива/списка.

Answer 3

Что такое столбец pm_messages_id в таблице pm_messages?

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

1. После того, как пользователь удалит его: удалите, если больше нет получателей.
2. Как задача cron или вручную в более позднее время: нет причин, по которым это удаление должно произойти сразу. Они просто сиротские записи, и их можно легко найти:

например.:

DELETE FROM pm_messages 
RIGHT JOIN pm_recipients ON pm_messages.id = pm_recipients.pm_messages_id 

Answer 4

(слишком долго для комментария)

Tehvans метод предполагает хранение списка участников для конкретного разговора, в то время как в методе участники сохраняются за сообщение. Я ожидаю, что причина этого заключается в том, чтобы разрешить удаление и прочтение, вопрос в том, почему это так?

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

В (почти) всех случаях удаление сообщений форума осуществляется автором/администратором и заставляет сообщение удаляться из представления всем пользователям.

Answer 5

Еще один пример использования (я знаю, что мои пользователи хотят этого) ... все хотят «отправленные предметы». Возможно, вы захотите рассмотреть этот вариант использования до того, как вы будете чистить дом.

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

Создайте триггер, который сделает это за вас. Весь ваш код приложения должен сделать, это беспокоиться о том, чтобы установить ваш «удаленный» столбец в true и иметь триггер запуска UPDATE, когда все флаги сообщения удаляются.

Курс, следующее, что вы знаете, ваши пользователи захотят удалить их. Лично я никогда не удаляю сообщение из базы данных, просто спрячу его от пользователя.