IM 的數據庫設計

本文主要是給一些開始接觸IM系統，作客戶端本地數據庫的人員介紹的。若有錯誤還請指出，thx.

本身目前作過兩個IM系統，接觸過通常經常使用的IM，都是本身開發沒用第三方的，因此就總結一下IM系統中客戶端的數據庫的基本設計的字段。

這裏只是通常須要字段，針對本身的需求(不少時候須要根據UI進行修改定製)，須要本身看需求添加or刪除。

主要表

通常主要須要創建的表包括：

1. 會話表

2. 聊天詳情表

3. 羣組表

4. 羣組信息表

5. 羣成員

6. 聯繫人表

表字段設計

a. 會話表

通常主要的字段以下：

id->auto increament primary key 自增加主鍵

uid->integer/varchar 該條消息所屬消息，好比我登錄了，我發送/接收到消息入庫的時候寫入本身的uid，他的做用是多用戶登錄的時候區分回話表

chatId->integet/varchar 服務器生產回話 id當前的回話id，它做用是標識一個回話，好比我跟你聊天or 你跟我聊天，咱們的回話id應該是一致的，對於羣聊也是，在羣中發送消息，每一個人的回話id是一致的。

c_id->varchar unique，他是標記一臺設備上某個用戶的惟一回話，用於更新避免插入多條數據的，能夠用到sqlite的update or replace，他的值能夠是hash(uid+chatid)或者其餘，該字段能夠只是客戶端具備，客戶端生成而且本身維護。

from->integer/varchar 發送人id(本身發送就是本身的uid，否則就是別人的uid)

to->integer/varchar 接收人id(uid/group_id)

last_msg->varchar 最後的一條消息內容
last_msg_id->integer/varchar  最後一條消息的id，做用是用於比較，好比在聊天頁面中，刪除了一條消息，撤回了一條消息之類的，這時候能夠根據這個msg_id進行刪除修改和更新。
chat_name -> varchar 聊天者的名稱，好比我與你聊天，個人表中的這個字段就是你的name,你的表中就是個人name.

last_user_name->varchar 最後的發送者名稱

last_time->integer 最後消息發送時間

chat_type->integer 回話類型(羣組消息/我的聊天/系統消息)

msg_type->integer 消息類型(文字/圖片/文件/音樂等)

unread_count->integer 改回話未讀數目

複製代碼

該表注意的問題：同一個回話不要插入多條數據，利用c_id來進行replace數據，好比收到一個新的回話消息存在就更新就行了。能夠用觸發器也能夠用sql語句。

b. 聊天詳情表

字段設計：

id->integer auto increament primary key 自增加主鍵

msg_id 消息惟一id，通常服務器生成，或者客戶端本地使用UUID生成

uid->Interger/varchar 所屬者uid

is_me->Integer 是不是本身發送的(UI顯示區分)

from->Interger/varchar  發送者uid(能夠是本身)

from_avatar->Interger/varchar 發送者頭像

from_name-> varchar 發送者名稱

to-> Interger/varchar 接受者(uid/group_id)

chat_type 會話類型

msg_type 消息類型

msg-> 消息內容

file_info->文件信息json格式

send_time->發送時間

send_status->發送狀態 發送中，發送完成，發送失敗

extra->把人插入 通常能夠爲null，預留的額外字段，使用JOSN字符串存儲

複製代碼

c. 羣組表

字段設計

id->integer auto increament primary key 自增加主鍵

group_id Integer/varchar unique

group_name varchar 羣組名稱

group_name 羣組頭像

group_type 羣組類型

group_num 羣組數量

group_create_uid 羣組建立者uid

複製代碼

d. 羣組信息表

羣組信息的字段能夠繼承羣列表的字段。字段設計

id->integer auto increament primary key 自增加主鍵

group_id Integer/varchar unique

group_name varchar 羣組名稱

group_name 羣組頭像

group_type 羣組類型

group_num 羣組數量

create_time 建立時間

group_create_uid 羣組建立者uid

group_intrduce 羣組簡介

nick_name 我的的羣暱稱字段。

group_role 羣組角色字段，好比你是管理員/羣主/普通成員等 該字段的做用是能夠用來作一個權限控制，好比在一些羣裏面，須要特定的人才能夠拉人，須要羣主才能夠刪除成員等，該字段是server下發的，根據不一樣的uid請求返回不一樣的role。

group_members 部分羣成員的List的JSON數據，該字段看UI設計，可能有的UI在羣信息頁面默認顯示幾個羣成員，而後點擊進入經過另外的接口查看所有羣成員。若是是這種狀況下，能夠在羣信息接口下發該羣的一些必要顯示成員既可。固然，這個字段也能夠不用，用一個或者羣成員接口替換，查看羣信息的時候也同時請求羣信息和羣成員接口也能夠。

複製代碼

e. 羣成員表

字段設計

id->integer auto increament primary key 自增加主鍵

group_id Integer/varchar

user_name varchar 用戶名

user_avatar varchar 頭像

group_role 角色

複製代碼

f. 聯繫人列表

字段設計

id->integer auto increament primary key 自增加主鍵

uid Integer/varchar unique

sex integer

birthday date


user_name varchar 用戶名

user_avatar varchar 頭像

relation interger 關係:好比好友/陌生人

複製代碼

其餘

1. 可能在有些需求中，消息還會區分平臺，好比ios/andoid/mac/windos等

2. 關於信息的更新：某一我的的我的頭像or暱稱發生了變化，這時候，咱們對應的消息頁面的UI，朋友列表等須要更新。這種類型的通知，通常是經過tcp推送，後臺經過查找該用戶的uid而後查找到他的會話跟好友列表而後進行推送。

3. 關於消息的設計：目前我所見是2種，一種是類型微信的常見，具備離線消息的概念，可是一旦客戶端確認接收到，服務器將不會保存，也就是不能跨設備保存用戶記錄，通常用tcp實現。還有一種是有一個同步消息的概念能夠跨設備，這種狀況下通常使用Tcp+Http實現。他們的邏輯相差仍是比較大。