分享網站群發站內信數據庫表設計。本站提示廣大學習愛好者：（分享網站群發站內信數據庫表設計）文章只能為提供參考，不一定能成為您想要的結果。以下是分享網站群發站內信數據庫表設計正文
“站內信”有兩個根本功效。一：點到點的新聞傳送。用戶給用戶發送站內信；治理員給用戶發送站內信。二：點到面的新聞傳送。治理員給用戶（指定知足某一前提的用戶群）群發新聞。點到點的新聞傳送很輕易完成，本文不再胪陳。上面將依據分歧的情形，來講說“站內信”的群發是若何完成的。
第一種情形，站內的用戶是大批級其余。（幾十到上百）
這類情形，因為用戶的數目異常少，是以，沒有需要過量的斟酌數據庫的優化，采取簡略的表格，對體系的設計也來的簡略，前期也比擬輕易保護，是典范的用空間換時光的做法。
數據庫的設計以下：表名：Message
ID：編號；SendID：發送者編號；RecID：接收者編號（如為0，則接收者為一切人）；Message：站內信內容；Statue：站內信的檢查狀況；PDate：站內信發送時光；
假如，某一個治理員要給一切人發站內信，則先遍歷用戶表，再依照用戶表中的一切用戶順次將站內信拔出到Message表中。如許，假如有56個用戶，則群發一條站內信要履行56個拔出操作。這個懂得上比擬簡略，比擬耗費空間。
某一個用戶上岸後，檢查站內信的語句則為：
Select * FROM Message Where RecID=‘ID' OR RecID=0
第二種情形，站內的用戶中量級其余（上千到上萬）。
假如照樣依照第一種情形的思緒。那發一條站內信的效果根本上就是後台瓦解了。由於，發一條站內信，得反復上千個拔出記載，這還不是最重要的，症結是上千甚至上萬筆記錄，Message字段的內容是一樣的，而Message有年夜量的占用存儲空間。比喻說，Message字段有100個漢字，占用200個字節，那末5萬條，就占用200×50000=10000000個字節=10M。簡略的一份站內信，就占用10M，這還讓不讓人活了。
是以，將本來的表格拆分為兩個表，將Message的主體放在一個表內，節儉空間的占用
數據庫的設計以下：
表名：Message
ID：編號；SendID：發送者編號；RecID：接收者編號（如為0，則接收者為一切人）；MessageID：站內信編號；Statue：站內信的檢查狀況；
表名：MessageText
ID：編號；Message：站內信的內容；PDate：站內信發送時光；
在治理員發一封站內信的時刻，履行兩步操作。先在MessageText表中，拔出站內信的內容。然後在Message表中給一切的用戶拔出一筆記錄，標識有一封站內信。
如許的設計，將反復的站內信的主體信息（站內信的內容，發送時光）放在一個表內，年夜量的節儉存儲空間。不外，在查詢的時刻，要比第一種情形來的龐雜。
第三種情形，站內的用戶是年夜量級的（上百萬），而且活潑的用戶只占個中的一部門。
年夜家都有如許的閱歷，某日看一個網站比擬好，一時心境彭湃，就注冊了一個用戶。過了一段時光，因為各種緣由，就忘卻了注冊時的用戶名和暗碼，也就不再上岸了。那末這個用戶就稱為不活潑的。從現實來看，不活潑的用戶占著不小的比例。
我們以注冊用戶2百萬，個中活潑用戶只占個中的10%。
就算是依照第二種的情形，發一封“站內信”，那得履行2百萬個拔出操作。然則個中的有用操作只要10%，由於別的的90%的用戶能夠永久都不會再上岸了。
在這類情形下，我們還得把思緒換換。
數據庫的設計和第二種情形一樣：
表名：Message
ID：編號；SendID：發送者編號；RecID：接收者編號（如為0，則接收者為一切人）；MessageID：站內信編號；Statue：站內信的檢查狀況；
表名：MessageText
ID：編號；Message：站內信的內容；PDate：站內信發送時光；
治理員發站內信的時刻，只在MessageText拔出站內信的主體內容。Message裡不拔出記載。
那末，用戶在登錄今後，起首查詢MessageText中的那些沒有在Message中有記載的記載，表現是未讀的站內信。在查閱站內信的內容時，再將相干的記載拔出到Message中。
這個辦法和第二種的比擬起來。假如，活潑用戶是100%。二者效力是一樣的。而活潑用戶的比例越低，越能表現第三種的優勝來。只拔出有用的記載，那些不活潑的，就不再占用空間了。
以上，是我對群發“站內信”的完成的設法主意。
作者：萬倉一黍
