需求 ：單使用者之間通訊（融合了使用者反饋需求）
資料庫設計：message內容和收發者存在一張表中
status:已讀、未讀、已刪
每當發信者發訊息時，就向資料庫中寫入兩條資料，相當於推送式。
推送式：
優勢：在使用者量（百、千）和訊息量較少時，資料庫操作效率高，無需聯表查詢；
劣勢：不適合**，重複儲存文字內容。
比方說，message欄位有100個漢字，占用200個位元組，那麼5萬條，就占用200×50000=10000000個位元組=10m。簡單的乙份站內信，就占用10m，這還讓不讓人活了。
需求：增加*企業管理員*和*系統管理員*的通知功能，即特殊使用者的一對多功能
資料庫設計：兩張表，message儲存訊息內容，messagelog儲存關係
type：private：單對單 、 public：企業通知、 global：系統通知；
from_id:儲存了發信者的userid，因為信的傳送者是固定的，和傳送日期、資訊內容一樣是固有資訊可以放在一起，若放在messagelog中冗餘。
from_status：message在傳送者處的狀態。同樣是三種。
messagelog表
單使用者間發件處理：
傳送郵件，插入message和messagelog表各一條記錄。（推送式）
企業或者系統發件處理（通知）：
傳送郵件，插入message一條記錄，在使用者讀取收件箱時從message中拉取通知。（拉取shi）
拉取式：
優點：「不用一次性插入n條，且不會產生無效的記錄」。只有活躍使用者才儲存收取通知的記錄，發件後再未登入的使用者不會儲存。
缺點：聯表查詢，時間複雜度更高
查詢rec_id=userid的記錄,取message_id和rec_status;
（處理通知）查詢messagelog表中，符合條件(type=global or (type=public and company_id= user.company )) and create_time > user.registertime 這些notice，把這些notice和2中的message_id集取交集，非交集中的notice顯示未讀狀態，其他資訊按2中讀取的rec_status顯示。
以上還有messag可見有效期的簡單處理，使用者註冊前的通知不可被使用者收到；
1.考慮當使用者的company欄位變更時對之前那些收到的company通知處理,個人認為在轉企時變更使用者其他資訊時，也把原company的通知也同步到使用者的messagelog記錄中；也可以不管那些未讀的原comopany通知；也可以把已處理的原company通知從messagelog中刪除。這個得看業務要求，而且轉企這種請求很少發生。
2.考慮普通使用者下的1->n，當n不大時，可仍然按單對單的推送式處理；n很大時，就按通知處理方法。
**「站內信」的實現
**「站內信」的實現（續）
兩年後，再議「站內信」的實現
百萬級使用者量的站內信**資料庫設計
站內信系統的設計思路
站內信是很多系統中的必備模組，結構設計也是老生常談的問題。設計如下，其中mail表示使用者 使用者之間的站內訊息，notice表示系統 使用者之間的系統通知 兩者結構基本一致，由於訊息體本身可能包含text這種大容量的資料內容，因此將訊息體獨立儲存在乙個表中，再將訊息體與收件方關聯，是更加高效一些的...
資料庫設計之站內信設計
最近做 有個站內信功能，站內信和郵箱的功能類似，只不過不通過郵件伺服器傳送，而是直接將記錄儲存在資料庫中，要求做到能發能收能刪，能 想了下，設計如下，歡迎看到這篇文章的朋友給出建議 發件表，收件表，內容表分離，發件表中儲存傳送與草稿兩種郵件，傳送多個郵件時，收件表的收件人id與刪除狀態為填寫多個，以...
電商系統百萬級站內信系統設計（主要資料庫設計）
大家知道，電商系統都是百萬級以上的使用者活動量，如果用正常的思路設計的程式，肯定是有很多漏洞和效能無法滿足系統的需求，那麼為了解決這個問題，本人特意寫下部落格給有需要的或者正在開發的新人一點設計思路。寫的好的地方請借鑑，不好的地方請指正 設計兩張表，一張是訊息表，另一張是訊息狀態表。傳送站內公告的時...