私信訊息準系統資料庫設計

來源:互聯網
上載者:User
本文通過資料庫層面來解析私信訊息準系統的實現。

項目需求:私信功能,實現像對方發送私信訊息後,在我的私信列表頁面顯示與發送或者接受訊息的人列表,列表每條記錄只顯示與該對話的最新的一條訊息。 點擊列表中的任意一條,進入到訊息對話詳情頁面,按照倒序顯示該對話的詳細內容。同時在這兩個頁面都可以進行刪除對話,私信列表頁面刪除是與對方的所有會話,私信詳情頁面刪除的是某一條對話,而且單方刪除對話記錄,不影響對方查看。

軟體環境: mysql

說了這麼多,其實總結起來就那麼幾個重要的點,一是私信列表每條記錄只顯示最後一條記錄,二是單方刪除對話記錄,不影響對方查看。先上資料表,然後在逐一解釋下。

CREATE TABLE `private_message` (  `id` bigint(20) NOT NULL auto_increment COMMENT '主鍵Id',  `user_id` bigint(20) NOT NULL COMMENT '寄件者Id',  `friend_id` bigint(20) NOT NULL COMMENT '接受者Id',    `sender_id` bigint(20) NOT NULL COMMENT '寄件者id',    `receiver_id` bigint(20) NOT NULL COMMENT '接受者Id',    `message_type` tinyint(4) NOT NULL COMMENT '訊息類型,1:普通訊息 2:系統訊息',    `message_content` varchar(500) NOT NULL COMMENT '訊息內容',    `send_time` datetime NOT NULL COMMENT '訊息發送時間',    `status` tinyint(4) NOT NULL default '1' COMMENT '訊息狀態 1:未讀 2:已讀 3:刪除',  PRIMARY KEY  (`id`)) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;123456789101112

建立private_message表,欄位說明:

id:主鍵,自增長 user_id: 寄件者id,非真實寄件者id friend_id: 接受者id,非真實接受者id sender_id:寄件者id,真實的寄件者id receiver_id:接受者id,真實的接受者id message_type:訊息類型,1:普通訊息 2:系統訊息,區分訊息列表,可以發送不同類型的訊息內容 message_content:訊息內容 send_time:訊息發送時間 status:訊息狀態 1:未讀 2:已讀 3:刪除,標記不同訊息狀態,可以實現統計未讀訊息數,邏輯刪除使用者恢複等

看到這裡大家該鬱悶了,怎麼弄兩個寄件者id,接受者id呢?

這裡因為考慮到單方刪除記錄,不影響對方查看的功能,所以這裡面我們需要在發送私信時,插入兩份一樣content內容的資料,但是在user_id,friend_id上面做點手腳了,在兩次插入資料時,第二次插入的資料跟第一次插入的資料的user_id和friend_id對調。也就是:

INSERT INTO `private_message` VALUES ('1', '121', '127', '121', '127', '1', 'hello word', '2015-09-09 10:25:43', '2');INSERT INTO `private_message` VALUES ('2', '127', '121', '121', '127', '1', 'hello word', '2015-09-09 10:26:41', '1');INSERT INTO `private_message` VALUES ('3', '127', '121', '127', '121', '1', '你是程式猿嗎?', '2015-09-11 10:30:16', '2');INSERT INTO `private_message` VALUES ('4', '121', '127', '127', '121', '1', '你是程式猿嗎?', '2015-09-11 10:30:59', '2');1234

這麼一來,就可以滿足我們的需求了。第一條和第四條記錄是給121使用者看,第二條和第三條記錄是給127看的,121刪除的時候刪除第一條或者第四條記錄,當然不會影響127看第二條和第三條記錄啦!!!

好了,現在可以搞定其他的功能需求了。
1、我的私信列表

SELECT p.id, COUNT(p.id) AS message_count,p.user_id,p.friend_id,p.sender_id,p.receiver_id,p.send_time,p.message_content, u.`name` AS receiver_name,u.img_url AS receiver_image FROM (SELECT * FROM private_message ORDER BY id DESC) p INNER JOIN user u on u.id=friend_id WHERE p.user_id=121 and p.`status` !=3 GROUP BY p.friend_id ORDER BY p.id DESC limit 0,101

2、我的私信列表詳情

SELECT p.id,p.message_content,p.sender_id,p.receiver_id,p.send_time,u.`name` AS sender_name,u.img_url AS sender_image,uu.`name` AS receiver_name FROM private_message p INNER JOIN user u on u.id=p.sender_id INNER JOIN user uu on uu.id=p.friend_id WHERE p.user_id=121 and p.friend_id=127 and p.`status` !=3 ORDER BY p.id DESC limit 0,101

3、我的私信列表頁面刪除整個會話

UPDATE private_message SETstatus=3 WHERE user_id=121 AND friend_id=1271

4、我的私信列表詳情刪除單個對話

UPDATE private_message SET status=3 WHERE id=11

5、擷取使用者未讀訊息數量

SELECT COUNT(*) FROM private_message WHERE user_id=121 AND receiver_id=127 AND status=11

當然,還可以更新未讀訊息為已讀,將已刪除的使用者從資源回收筒中恢複過來,發送系統訊息等等都可以實現的啦。這是,肯定有同學會說了,這個表設計的資料冗餘,每條記錄插入兩遍,content內容多的話或者發送系統訊息時,表資料太大,當然這個只是針對小型的私信功能,肯定跟大型專註於社交類網站不一樣了,但是我們也可以將content內容拆分出去,建立一個content表,這裡關聯下id就可以減少資料冗餘了。還有就是這個設計不涉及到高並發訪問啦!涉及到高並發這個那就得更複雜的設計和方法途徑解決啦!


相關閱讀:

php 聊天一對一聊天功能原始碼

如何使資料庫索引的使用效率更高?

設計資料庫的一般步驟及例子

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.