在微博系統中，當前使用者、關注者（也就是粉絲）、被關注者（崇拜物件）這三種角色是少不了的。他們之間看似簡單的關係，但是其中資料庫表將如何設計，卻讓我很難琢磨，在如下解決方案中，你們會選擇哪種?為什麼要選擇這種?是否有更好的解決方案?
解決方案一：
表名使用者資訊表
欄位名
字段**
字段型別
描述
使用者名稱user_id
varchar(20)
主鍵登陸密碼
password
varchar(20)
表名關注和被關注者表
欄位名
字段**
字段型別
描述
使用者名稱user_id
varchar(20)
主鍵關注者
funs
text
被關注者
wasfuns
text
這是我最初想到的一種設計，這裡「關注者」和「被關注者」都是採用拼接一些特殊字元分割儲存的，比如a使用者有只有關注者b、c、d、e，那麼存入資料庫關注者字段的資料將是b;c;d;e（暫且認為分割字元為；）。
基於上述方案，我提出乙個問題：當這個使用者的「關注者」或「被關注者」數量很大的情況下（比如10萬個關注者）將是怎樣的一串字元呢？而且當我們需要查詢「關注者」或者「被關注者」最近的部落格資訊，將面臨和博文資訊表的一些時間排序查詢，處理難度是要浪費效能的。
解決方案二：
基於上述面臨的問題，有人給我提供了乙個擴充套件性的解決方案，同時也很好的解決了乙個字段海量資料的問題。將方案一中的關注和被關注者表分解成兩張表，如下：
表名關注者表
欄位名
字段**
字段型別
描述編號
idnumber
主鍵使用者名稱
user_id
varchar(20)
關注者編號
funs_id
varchar(20)
表名
被關注者表
欄位名
字段**
字段型別
描述編號
idnumber
主鍵使用者名稱
user_id
varchar(20)
被關注者編號
wasfuns_id
varchar(20)
我看到這樣的設計我很吃驚，試想一下，假如我乙個使用者對應有1w個關注者，那麼該使用者就會在關注者表中存在一萬條他的記錄，這難道不是嚴重的資料冗餘嗎？這甚至不符合資料庫的設計規範。但是事實上證明，這種設計對大資料量的擴充套件是很不錯的，既然如此，那假如使用者和使用者之間的關係不只是限於關注和被關注的關係，是不是又要新增表？
解決方案三：
話說「合久必分，分久必合」，對上述的設計再進一步修改，於是將方案二的兩張表又合二為一，如下：
表名關注和被關注者表
欄位名
字段**
字段型別
描述編號
idint
主鍵使用者名稱
user_id
varchar(20)
目標物件
operate_object
varchar(20)
狀態
status
number
當目標物件為關注者，標示為1；
當目標物件為被關注者，標示為2；
當雙方互相關注，標示為3；
當目標物件為oo，標示為xx。
ok，這樣的設計不僅解決了相當一部分的資料冗餘，而且還能表示使用者之間的多種關係，方便系統日後的擴充套件。但是問題又出來了，很明顯這樣設計對狀態的維護也是存在疑問的，用一張表代替多張表，資料肯定是成倍的增長，是否不符合當前常說的「拆庫拆表」的戰略方針（好像這樣的狀態一般用於「標記男女」或者「是否刪除了」之類的，貌似用於這種場合比較的少）。
在上述使用者關係的解決方案中，可以很簡單的歸結為就是一對多，多對一，多對多的關係嘛，那麼究竟如何設計，究竟哪種更好，希望大家共同分析！
實現乙個簡單的資料庫
所有應用軟體之中，資料庫可能是最複雜的。mysql的手冊有3000多頁，postgresql的手冊有2000多頁，oracle的手冊更是比它們相加還要厚。但是，自己寫乙個最簡單的資料庫，做起來並不難。reddit上面有乙個帖子，只用了幾百個字，就把原理講清楚了。下面是我根據這個帖子整理的內容。第一步...
乙個站內簡訊的資料庫設計
先說一下需求和環境 乙個系統的站內信模組，有存在大量的按部門 的可能，相對的個人對個人的 是比較少的。資料庫是採用的mysql5.0。最先的資料庫設計如下 兩張表 一張msg表，字段如下 id int 自增長id senderid int 外來鍵關聯傳送者id title varchar 128 簡...
乙個站內簡訊的資料庫設計
先說一下需求和環境 乙個系統的站內信模組，有存在大量的按部門 的可能，相對的個人對個人的 是比較少的。資料庫是採用的mysql5.0。最先的資料庫設計如下 兩張表 一張msg表，字段如下 id int 自增長id senderid int 外來鍵關聯傳送者id title varchar 128 簡...