上一篇寫了基於resin4.0+websocket實現私信功能服務端消息推送文章，趁熱打鐵，在寫一篇關於私信功能的數據庫設計文章，非代碼篇，希望想對第一次做設計並開發私信功能的同學有點幫助。
項目需求：私信功能，實現像對方發送私信消息后，在我的私信列表頁面顯示與發送或者接受消息的人列表，列表每條記錄只顯示與該對話的最新的一條消息。 點擊列表中的任意一條，進入到消息對話詳情頁面，按照倒序顯示該對話的詳細內容。同時在這兩個頁面都可以進行刪除對話，私信列表頁面刪除是與對方的所有會話，私信詳情頁面刪除的是某一條對話，而且單方刪除對話記錄，不影響對方查看。（有點繞。。。）
軟件環境： 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;
1
2
3
4
5
6
7
8
9
10
11
12
建立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');
1
2
3
4
這么一來，就可以滿足我們的需求了。第一條和第四條記錄是給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,10
1
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,10
1
3、我的私信列表頁面刪除整個會話
UPDATE private_message SETstatus=3 WHERE user_id=121 AND friend_id=127
1
4、我的私信列表詳情刪除單個對話
UPDATE private_message SET status=3 WHERE id=1
1
5、獲取用戶未讀消息數量
SELECT COUNT(*) FROM private_message WHERE user_id=121 AND receiver_id=127 AND status=1
1
當然，還可以更新未讀消息為已讀，將已刪除的用戶從回收站中恢復過來，發送系統消息等等都可以實現的啦。這是，肯定有同學會說了，這個表設計的數據冗余，每條記錄插入兩遍，content內容多的話或者發送系統消息時，表數據太大，當然這個只是針對小型的私信功能，肯定跟大型專注於社交類網站不一樣了，但是我們也可以將content內容拆分出去，新建一個content表，這里關聯下id就可以減少數據冗余了。還有就是這個設計不涉及到高並發訪問啦！涉及到高並發這個那就得更復雜的設計和方法途徑解決啦！
最后，貼上項目私信功能截圖，作為對上邊的設計的體現吧！
我的私信列表頁面：
我的私信列表詳情頁面：
————————————————
版權聲明：本文為CSDN博主「哎_小羊_168」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/aixiaoyang168/article/details/49304823