先說一下需求和環境：
乙個系統的站內信模組，有存在大量的按部門**的可能，相對的個人對個人的**是比較少的。
資料庫是採用的mysql5.0。
最先的資料庫設計如下：
兩張表：
一張msg表，字段如下：
id int 自增長id
senderid int 外來鍵關聯傳送者id
title varchar(128) 簡訊標題
content varchar(512) 簡訊內容
createtime datatime 發信時間
status tinyint 發件箱中的狀態：0--普通；1--刪除
一張user_has_msg表，字段如下：
id int
departmentid int 部門**的時候外來鍵關聯部門id，可以為空
receverid int 外來鍵關聯收信人，可以為空
msgid int 外來鍵關聯簡訊息
status tinyint 收件箱狀態：0--普通；1--刪除
readstatus tinyint 閱讀狀態：0--未讀；1--已讀
這樣設計是基於如下考慮的：
首先，msg表包含了發件箱所需要的所有資訊，程式的時候寫發件箱的時候可以只考慮操作一張資料庫表。
第二，user_has_msg中，departmentid主要考慮的是存在大量的按照部門**的可能，這樣的話，**給乙個部門的時候之需要在兩張表上個記錄一條資料，而不需要在user_has_msg中記錄該部門員工數條記錄。
但是，後來這個方案被我自己和同事討論後否決了，原因如下：
首先,departmentid的存在使得沒有使用者可以刪除收件箱中的站內信，因為刪除了，其他人的收件箱裡也看不到。
第二，msg表不能保證顯示完所有的發件箱所需要的資料，因為只有著一張表的是後讀不出來收件人資訊。
修改後的版本是：
將msg修改為只保純粹的資訊的表：
id int 自增長id
title varchar(128) 簡訊標題
content varchar(512) 簡訊內容
createtime datatime 發信時間
將user_has_msg修改為儲存各種關係和狀態的表：
id int
senderid int 外來鍵關聯傳送者id
receverid int 外來鍵關聯收信人
msgid int 外來鍵關聯簡訊息
sendstatus tinyint 發件箱中的狀態：0--普通；1--刪除
recevestatus tinyint 收件箱狀態：0--普通；1--刪除
readstatus tinyint 閱讀狀態：0--未讀；1--已讀
我記錄這個的想法一方面想記錄我自己的一些積累，另一方面是想像在網上找到更好的設計方法，尤其是解決**這個問題。
乙個站內簡訊的資料庫設計
先說一下需求和環境 乙個系統的站內信模組，有存在大量的按部門 的可能，相對的個人對個人的 是比較少的。資料庫是採用的mysql5.0。最先的資料庫設計如下 兩張表 一張msg表，字段如下 id int 自增長id senderid int 外來鍵關聯傳送者id title varchar 128 簡...
資料庫設計之站內信設計
最近做 有個站內信功能，站內信和郵箱的功能類似，只不過不通過郵件伺服器傳送，而是直接將記錄儲存在資料庫中，要求做到能發能收能刪，能 想了下，設計如下，歡迎看到這篇文章的朋友給出建議 發件表，收件表，內容表分離，發件表中儲存傳送與草稿兩種郵件，傳送多個郵件時，收件表的收件人id與刪除狀態為填寫多個，以...
資料庫設計正規化 如何設計乙個資料庫結構
正規化 英文名稱是 normal form，它是英國人 e.f.codd 關聯式資料庫的老祖宗 在上個世紀70年代提出關聯式資料庫模型後總結出來的，正規化是關聯式資料庫理論的基礎，也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化，依次是 1nf，2nf，3nf，b...