大家都知道站內信，分為少量（10-999使用者），中量（1000-99999使用者），大量（100w使用者）不同的站內信架構，消耗儲存空間，和效率也是不同的。
本人基於最大的架構，來於大家共同討論，站內信這個小功能，究竟要怎麼設計，才能更節約空間。下面是基於我個人的一些見解：
站內信的功能是：
1、使用者與使用者之間的交流，像郵件形式。
2、管理員給使用者發站內信。
3、管理員**訊息給所有的使用者（對於100w使用者，你要怎麼做？）
開門見山,先看看我設計的資料庫表關係：
message表：
messageid：標識列； sendid：發件人id； recid：收件人id； textid：訊息id； status：標識已讀1/未讀0；
messagetext表：
textid：標識列； titel：標題； text：信件內容； time：發件時間；
sysmessag表:
sysid:標識列； customerid：使用者標識列； messageid：訊息標識列； sysstatus：系統訊息已讀1/未讀0；
乙個使用者需要接收多條系統資訊，而每條系統資訊則會有乙個對應的訊息狀態，所以這張表是對應沒條系統訊息的乙個狀態的判斷。
所有標識列都是主鍵
三張表關係就是這樣子：
表設計就是這個樣子，用到三張表。
現在需要來檢驗我的設計的時候了，假如，管理員給所使用者**訊息的傳送id=0也就是recid = 0
我需要在message表中插入一條記錄，格式如同這樣子：
這條系統訊息已經記錄在資料庫中
現在使用者都讀不到這條資訊，現在模擬，假如有乙個使用者登陸了帳號，接下來要做的就是：
1、首先讀取recid中有沒有與該使用者id匹配的訊息，目前結果是沒有；
2、之後再匹配recid=0的系統訊息數量，現在有一條，messageid=1；
3、然後就對系統訊息表sysmessag 插入現有的一條記錄插入之後，也就像下面這樣：
sysstatus狀態預設為未讀0。
4、如果有多條資訊的話，就執行多條插入操作，（什麼？會有很多系統訊息？ 你見過系統訊息有上百條？就算有上百條，資料執行100次插入 我想問題也不大吧？ - -||）
5、最後取訊息的總數message+sysmessag，反饋給前台，現在是1。
模擬到此結束。 o(∩_∩)o
使用者已讀系統訊息只能修改存於sysmessag 中的sysstatus的狀態，不能去修改message表中的狀態，我想這個是可控的。
（什麼？你說使用者發訊息的時候輸入recid=0？這個許可權問題你不能控制？ 那我真不知道說什麼好了。^_^ ）
有100w的使用者現在只會依據活躍使用者而占用儲存空間，而不活躍的使用者，根本不用再去為浪費的儲存空間而煩惱了。
看完之後，想必大家對站內信設計，也有自己的看法觀點，歡迎評價，提出您寶貴的意見，讓我學到更多考慮問題的角度，謝謝
站內信系統的設計思路
站內信是很多系統中的必備模組，結構設計也是老生常談的問題。設計如下，其中mail表示使用者 使用者之間的站內訊息，notice表示系統 使用者之間的系統通知 兩者結構基本一致，由於訊息體本身可能包含text這種大容量的資料內容，因此將訊息體獨立儲存在乙個表中，再將訊息體與收件方關聯，是更加高效一些的...
單系統站內信資料庫設計思路
需求 單使用者之間通訊 融合了使用者反饋需求 資料庫設計 message內容和收發者存在一張表中 message表 這裡一條message存兩次，類似郵件服務。status 已讀 未讀 已刪 每當發信者發訊息時，就向資料庫中寫入兩條資料，相當於推送式。推送式 優勢 在使用者量 百 千 和訊息量較少時...
資料庫設計之站內信設計
最近做 有個站內信功能，站內信和郵箱的功能類似，只不過不通過郵件伺服器傳送，而是直接將記錄儲存在資料庫中，要求做到能發能收能刪，能 想了下，設計如下，歡迎看到這篇文章的朋友給出建議 發件表，收件表，內容表分離，發件表中儲存傳送與草稿兩種郵件，傳送多個郵件時，收件表的收件人id與刪除狀態為填寫多個，以...