站內信是很多系統中的必備模組，結構設計也是老生常談的問題。
設計如下，其中mail表示使用者-->使用者之間的站內訊息，notice表示系統-->使用者之間的系統通知：
兩者結構基本一致，由於訊息體本身可能包含text這種大容量的資料內容，因此將訊息體獨立儲存在乙個表中，再將訊息體與收件方關聯，是更加高效一些的做法。
在多數應用場景中，可能會包含**行為，例如：使用者傳送給好友的祝福；系統向部分使用者傳送通知。此時，遍歷目標使用者，批量插入至訊息接收表，是比較可靠的做法。
但是相對於mail站內信而言，notice有乙個重要的需求是【廣播】，即面向所有註冊使用者的**訊息。面對這種需求，當使用者只有幾十人時，這與前面的方法並無顯著的差異。但是當使用者體量過千，甚至過萬的時候，這將是非常不智的做法。
更好一些的做法，是將notice訊息提設定為廣播屬性，當使用者發生操作時，才將訊息體匯入接收資訊表中。
關於此類訊息的查詢，通常採用如下方式：
select ifnull(nr.id, 0) as id, ifnull(nr.recipient_user_id, 0) as recipient_user_id, ifnull(is_read, 0) as is_read, ifnull(is_delete, 0) as查詢當前使用者的關聯資訊，以及所有廣播資訊，同時要注意，訊息體時間大於使用者註冊時間，避免出現歷史資訊出現的狀況。is_delete
, n.id
as notice_id, notice_content, is_broadcast, n.create_time as
notice_create_time
from
notice_receive nr
right
outer
join notice n on nr.notice_id =
n.id
where (nr.recipient_user_id = # or is_broadcast =
1) and nc.create_time > #
分析上面的sql語句，很明顯right outer join是很消耗系統效能的查詢操作，這並不是乙個更優的方案，還需要進一步優化。
再考慮一下使用者日常操作訊息的行為：未讀訊息設為已讀、未讀訊息直接刪除、已讀訊息刪除（類似於email系統的未讀和已讀之間的關係轉換，並無同質考慮的意義）。
上圖是很常見的訊息列表，結合前面的table結構，實際我們在做上面批量操作時，應有的查詢是：
where nr.id in (notice_receive id list)對於已經閱讀過的訊息，已經存在於notice_receive表中，可以直接根據notice_receive_id來操作。但是對於尚未閱讀操作過的資訊，則需要混合notice_id來進行操作，這樣一來可能需要混合處理語句來完成。
或許，在這種權衡選擇當中，在使用者登入、或者開啟訊息列表時，就將notice關聯存入notice_receive表，或許會更好的解決這個問題。
單系統站內信資料庫設計思路
需求 單使用者之間通訊 融合了使用者反饋需求 資料庫設計 message內容和收發者存在一張表中 message表 這裡一條message存兩次，類似郵件服務。status 已讀 未讀 已刪 每當發信者發訊息時，就向資料庫中寫入兩條資料，相當於推送式。推送式 優勢 在使用者量 百 千 和訊息量較少時...
站內信設計
站內信設計 1 message表 欄位名 型別 是否null id int 自增長 否 messageid int 否 sendid int 否 reclid int 否 readstatus int 否 sendstatus int 否 id 編號 messageid 訊息id sendid 傳送...
站內信設計
一 網上站內信技術方案 站內信 不同於電子郵件，電子郵件通過專門的郵件伺服器傳送 儲存。而 站內信 是系統內的訊息，說白了，站內信 的實現，就是通過資料庫插入記錄來實現的。站內信 有兩個基本功能。第一，點到點的訊息傳送。使用者給使用者傳送站內信 管理員給使用者傳送站內信。第二，點到面的訊息傳送。管理...