随便想到，群聊天的資料庫簡單設計1，聊天消息設計2，就一個表3，簡化下4，增加配置表4，總結

突然想了想，如果一個群聊天資料庫到底應該咋設計。

從最簡單的思路慢慢開始。簡單到大家都能明白。

最簡單的方式，先完成功能。開發比較着急嘛，一個表資料存放友善。

資料庫表結構如下。

一個群的聊天記錄，一個消息發給多個人，每個人都收到一個相同的消息。

一般是不會這樣設計的吧。這個資料 比較備援啊。而且一個群下面人越多。

消息的重複數量越多。m*n條資料備援啊。

拆分成消息内容和流水表。

這樣會好一點，将消息内容存儲成一個表，然後每個人都隻有一個流水表。

但是這樣也有一個問題，隻是節省了内容字段。沒有節省流水。

還是 m*n 條消息記錄呢。

拆分成兩個表，一個是消息的流水表，一個是每個人的配置表。

記錄每個群下面的這個使用者的最後讀取的消息last_msg_id，然後在計算消息未讀資料。

這樣優化之後資料将減少好多，數量是 m+n條資料。不在是成倍增長了。

但是這個是個局限隻限于群聊天，因為這個隻是知道你這個群的未讀消息數量。

是以直接進行connt查詢就行。

總結，一個群消息的資料設計簡單的進行了幾次演化。

最後的方案比較好，隻有通過配置讀取最新的msg_id，然後再計算出使用者未讀數量。

基本上一個消息都是順序讀取的，一個流水，可以認為使用者也是順着讀的。

這樣就可以把消息的未讀資料用last_msg_id 進行計算。

感覺上qq上面的群消息應該也是這樣設計的吧。這樣設計才最節省資源。