設計篇--站內信設計思路之己見（基於上百萬用戶）

 

你們都知道站內信，分爲少許（10-999用戶），中量（1000-99999用戶），大量（100W用戶）不一樣的站內信架構，消耗存儲空間，和效率也是不一樣的。

本人基於最大的架構，來於你們共同討論，站內信這個小功能，究竟要怎麼設計，才能更節約空間。下面是

你們都知道站內信，分爲少許（10-999用戶），中量（1000-99999用戶），大量（100W用戶）不一樣的站內信架構，消耗存儲空間，和效率也是不一樣的。

本人基於最大的架構，來於你們共同討論，站內信這個小功能，究竟要怎麼設計，才能更節約空間。下面是基於我我的的一些看法：

站內信的功能是：

一、用戶與用戶之間的交流，像郵件形式。

二、管理員給用戶發站內信。

三、管理員羣發消息給全部的用戶（對於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表中插入一條記錄，格式如同這樣子：

這條系統消息已經記錄在數據庫中

如今用戶都讀不到這條信息，如今模擬，假若有一個用戶登錄了賬號，接下來要作的就是：

　　一、首先讀取Recid中有沒有與該用戶Id匹配的消息，目前結果是沒有；

　　二、以後再匹配RecId=0的系統消息數量，如今有一條，MessageID=1；

　　三、而後就對系統消息表SysMessag 插入現有的一條記錄插入以後，也就像下面這樣：

　　　　

　　　　SysStatus狀態默認爲未讀0。

　　四、若是有多條信息的話，就執行多條插入操做，（什麼？會有不少系統消息？  你見過系統消息有上百條？就算有上百條，數據執行100次插入 我想問題也不大吧？ - -||）

　　五、最後取消息的總數Message+SysMessag，反饋給前臺，如今是1。

模擬到此結束。     o(∩_∩)o

用戶已讀系統消息只能修改存於SysMessag 中的SysStatus的狀態，不能去修改Message表中的狀態，我想這個是可控的。

（什麼？你說用戶發消息的時候輸入RecId=0？這個權限問題你不能控制？ 那我真不知道說什麼好了。^_^ ）

有100W的用戶如今只會依據活躍用戶而佔用存儲空間，而不活躍的用戶，根本不用再去爲浪費的存儲空間而煩惱了。