用户消息系统(PHP / MySQL)

发布于 2024-10-12 23:38:58 字数 923 浏览 0 评论 0原文

我目前正在为我现有的网站开发一个用户消息系统(类似于 Facebook)。我已经有一个用户表,现在只需要集成一个消息系统。

我昨天开始讨论这个问题(用户消息系统)并取得了一些进展,但结构已经发生了很大变化有点所以我开始一个新问题。

我想知道的本质上是表结构应该是什么样子?需求如下:

  • 用户之间交换消息,一个发送者可以向多个接收者发送消息。

  • 消息以线程样式布局显示,作为一对一对话。即每个收件人的回复将显示在其自己的线程中。

  • 话题创建后,它将出现在发件人的“已发送邮件”文件夹中 - 除非收件人发送回复,否则它不会出现在收件箱中。

    话题
  • 无法删除单个消息,但可以删除线程。删除线程不会删除任何消息,它只是从用户的收件箱(或“已发送消息”文件夹)中删除该线程。如果其他用户尚未从他/她的收件箱(或“已发送消息”文件夹)中删除该话题,则他/她仍然可以访问该话题。

  • 发送消息或回复时,“已读状态”将设置为“未读” - 但这不会影响发件人。即只有收件人才应将其视为“未读”。

这是我目前所拥有的:

Table messages
==============
id
thread_id
from_user_id
subject
body
sent_date

Table message_threads
=====================
id
message_id
to_user_id
from_user_id
read_status

其他需要考虑的事情是,当向多个收件人发送相同的消息时,我们应该为每个收件人存储一条单独的消息,还是只存储一条消息?

任何指导将不胜感激。

I'm currently developing a user messaging system (similar to Facebook) for my existing site. I already have a users table and just need to integrate a messaging system now.

I started a thread on this yesterday (User messaging system) and made some progress but the structure has changed quite a bit so I'm starting a new question.

What I want to know is essentially what should the table structure look like? The requirements are as follows:

  • Messages are exchanged between users, and a sender can send a message to multiple recipients.

  • Messages are displayed in a thread-style layout, as a 1-1 conversation. i.e. each recipient's reply will appear in its own thread.

  • Once a thread is created it will appear in the senders 'sent messages' folder - it will not appear in their inbox unless the recipient sends a reply.

  • Individual messages cannot be deleted, however a thread can be deleted. Deleting a thread doesn't delete any messages, it just removes that thread from the user's inbox, (or 'sent messages' folder). The other user will still have access to the thread if he/she hasn't deleted it from his/her inbox (or 'sent messages' folder).

  • When a message or reply is sent, the 'read status' is set to 'unread' - but that should not affect the sender. i.e. only the recipient should see it as 'unread'.

Here is what I have at the moment:

Table messages
==============
id
thread_id
from_user_id
subject
body
sent_date

Table message_threads
=====================
id
message_id
to_user_id
from_user_id
read_status

Something else to think about is when sending the same message to multiple recipients, should we store a seperate message for each recipient, or just one message?

Any guidance would be highly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

可是我不能没有你 2024-10-19 23:38:58

我同意@Eddsstudio:当用户发送消息时,将其副本放入“已发送文件夹”中,并将副本放入收件人收件箱中。对于任何回复:在主发件人收件箱中创建一条新邮件,不链接到以前的邮件(即,没有链接到已发送文件夹中的邮件)。

您可以使消息在屏幕上向用户显示的方式看起来更像线程对话,但多消息后端会带来更少的麻烦。

I agree with @Eddsstudio: when the user sends a message put a copy of it in the "sent folder" and copies in the recipients inbox's. For any replies: create a new message in the primary senders inbox, not linked to the previous messages (i.e. no link to the message in the sent folder).

You can make the messages look more like a thread conversation in the way they're displayed on the screen to the user but a multiple message back-end will create far fewer headaches.

荒芜了季节 2024-10-19 23:38:58
$query = 'CREATE TABLE IF NOT EXISTS ' . $db->prefix . 'pm (
    `post_id` => $post->ID,
    `role_id` => $role_id,
    `sender` varchar(60) NOT NULL,
    `recipient` varchar(60) NOT NULL,
    `date` datetime NOT NULL,
    `read` tinyint(1) NOT NULL,
    `deleted` tinyint(1) NOT NULL,
    PRIMARY KEY (`id`)
) COLLATE utf8_general_ci;';

我相信拥有这种性质的结构会起作用。

$query = 'CREATE TABLE IF NOT EXISTS ' . $db->prefix . 'pm (
    `post_id` => $post->ID,
    `role_id` => $role_id,
    `sender` varchar(60) NOT NULL,
    `recipient` varchar(60) NOT NULL,
    `date` datetime NOT NULL,
    `read` tinyint(1) NOT NULL,
    `deleted` tinyint(1) NOT NULL,
    PRIMARY KEY (`id`)
) COLLATE utf8_general_ci;';

I believe having something structured in this nature would work.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文