消息群發,數據表設計規則

Question

消息群發表設計：
功能目的：
1. 群發的對象類型可能有：屬於不同群組的多人（也可以是單人），有群組關關係的多人（如：國家，省，市）． => 群發類型（message_type），接收人員（to_id）
2. 其中的人員又可能屬於不同的類型：老師，家長，學生，經銷商．（是否處於相同的表當中） => 人員類型（user_type）
3. 接收人員可以改變消息狀態． => 消息狀態（message_state）設計方案：
一、 以一個表來記錄消息與狀態，一個用戶的條消息用一個記錄來．
字段名 說明
Id 消息id號
From_id 發送人員id號
User_type 用戶類型
To_id 接收人員id號
Content 消息內容
Message_state 消息狀態優點：表結構清楚而且簡單．
缺點：當群發接收人數多時，一次性添加較多的記錄到表中，數據日增長大．二、 以一個表來記錄消息，另一個表來記錄消息狀態．
字段名 說明
Id 消息id號
From_id 發送人員id號
User_type 用戶類型
To_id 接收人員id號（將所有接收人員都保存在這個字段里）
Content 消息內容字段名 說明
Id
User_id 接收人員id號
Message_id 消息id號
Message_state 消息狀態
優點：表的分離
缺點：消息表中的“To_id”字段，當接收人多時，可能會非常長．消息狀態表中一個用戶的一條消息用一個記錄保存，會出方案一的現象．三、 同樣以一個表來記錄消息，另一個表來記錄消息狀態．
message：
字段名 說明
Id 消息id號
From_id 發送人員id號
Message_type 群發類型（多人（限定人數範圍），國家，省，市）
User_type 用戶類型
To_id 根據群發類型，填入對應的（接收人員id號，...）
Content 消息內容
user_message：
字段名 說明
Id
User_id 接收人員id號
Message_id 用戶讀過的信息id號
優點：一個信息用一條記錄，一個用戶的所有信息用一個記錄來保存，數據表記錄增長速度相對不會太快．
缺點：程序在檢索數據和添加數據時會比較麻繁．
查詢所有用戶的消息：其它方案正在思考中... ...各位有什麼好的方案沒有

Answer 1

按第三范式，第三种方法ms好些，但From_id Message_type这种对于同一消息来说重复的东西也要扔到user_message 里去的吧lz说的检索和添加比较麻烦，不知是什么意思？

Answer 2

第三種方式的話，消息表只記錄一次消息，然後用戶通過
Message_type 群發類型（多人（限定人數範圍），國家，省，市）
User_type 用戶類型
To_id 根據群發類型，填入對應的（接收人員id號，...） 這三個條件來判斷自己的新消息．也就是這條消息記錄只有一條並沒有冗餘．检索和添加麻煩．主要是在數據查詢時怎麼進行關聯查詢．

Answer 3

sql语句写写么总能查的吧 没啥效率瓶颈不就得了

Answer 4

Id    From_id    Message_type    User_type    To_id    Content
1     1          多人            學生         2,3,4,5  測試用戶在從To_id里檢索，這個消息是否屬於自己的．在這邊感覺這個sql語句寫起來有點怪select * from message left join user on user.id in (To_id),不過這樣好像不太行．

Answer 5

表A
Msg_Id     Key
Msg_FromId 发出者编号
Msg_ToId   接收者编号
Msg_ToType 接收者类型
[Msg_IsToType] 可选字段用于判断是否来群发向某类型
Msg_Expire 群发截止或其他~
…… #表B
Msg_Id     AutoIncrease Key
Msg_Title  短信标题
Msg_Conten 短信内容
Msg_Time   发送时间
…… #表C
Msg_Id    Key
Msg_State 1已接收 2已查看 3已删除……
…… #具体流程：
管理员添加群发消息-->用户上线--利用A,C表判断是否有未接收有效信息
-->Yes>新增C表信息记录用户已接收
-->No>此时 状况有2:1信息过期,2消息状态为 1,2,3……这样我们就利用了C表的状态值实现了单对单操作信息的效果.

Answer 6

呵呵，謝謝SysTem128的回復，根據你提供的表結構，我群發一個消息時，就得添加３條數據到３個表中．這樣的話，當發送給了10W個用戶是否就是要添加30w條記錄．或者可以採用某種數據表結構來避免大量的數據操作呢．

Answer 7

看来你没有理解这个方案是怎么运作的
A,B表只需要添加一次记录.
C表只包含三个数字字段.Msg编号User编号和状态.
如果你要发送给10万个用户的只需要添加10万零一条.
注意是'数字字段 10w条',查询速度不会很慢的.

Answer 8

还有一个方案……
但可操作性不是很强.
但是效率特别特别高……看到A表中的Expire字段了吧？我们只要记录出User接收的最后一条群发信息的过期时间就行了.
至于为什么说可操作性不强,自己实践下就知道了.

Answer 9

呵呵，還是謝謝SysTem128的回復， 由於我這邊的需求要求,用戶量可能會達到20W,並且要保存住用戶的消息的狀態.若採用你的這種方案,那要是有一個用戶每天都在給20W的用戶群發消息,那C表的增長速度會是相當可怕的,雖然它的結構比較簡單,但量大的時候會不會很不好維護,而且一段時間后這個表將會有多少條記錄.我後來想了一種方案,說給你聽聽,
表結構可以按你的方案,只是在C表不太一樣,但他一樣用來保存用戶消息的狀態.user_id                用戶id號
message_read_id        用戶已讀過的消息id號,用文本來保存以這種方式:1,2,3,
message_new_id         用戶的新消息,他的保存方式同上其中系統中的每一個用戶都對應在這個表中有一條記錄,相當於用戶的郵箱,每人都有一個.當用戶群發消息時,同樣在A,B表里添加消息記錄.而在C表,則更新message_new_id字段,將新的消息更新進來
而用戶在讀取新消息時只要從message_new_id記錄里讀出他相應的新消息
當用戶查看過新消息后,則要對message_read_id,message_new_id進行更新這種方案只是說可以保持C的記錄數,但他的更新效率應該也會是一個問題.你覺得這個怎麼樣呢