一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考
解決方案一:
表名 |
用戶信息表 |
||||
字段名 |
字段代碼 |
字段類型 |
描述 |
||
用戶名 |
User_id |
Varchar(20) |
主鍵 |
||
登陸密碼 |
Password |
Varchar(20) |
|||
…… |
…… |
…… |
|||
表名 |
關(guān)注和被關(guān)注者表 |
||||
字段名 |
字段代碼 |
字段類型 |
描述 |
||
用戶名 |
User_id |
Varchar(20) |
主鍵 |
||
關(guān)注者 |
Funs |
Text |
|
||
被關(guān)注者 |
Wasfuns |
Text |
這是我最初想到的一種設(shè)計,這里“關(guān)注者”和“被關(guān)注者”都是采用拼接一些特殊字符分割存儲的,比如A用戶有只有關(guān)注者B、C、D、E,那么存入數(shù)據(jù)庫關(guān)注者字段的數(shù)據(jù)將是B;C;D;E(暫且認(rèn)為分割字符為;)。
基于上述方案,我提出一個問題:當(dāng)這個用戶的“關(guān)注者”或“被關(guān)注者”數(shù)量很大的情況下(比如10萬個關(guān)注者)將是怎樣的一串字符呢?而且當(dāng)我們需要查詢“關(guān)注者”或者“被關(guān)注者”最近的博客信息,將面臨和博文信息表的一些時間排序查詢,處理難度是要浪費性能的。
解決方案二:
基于上述面臨的問題,有人給我提供了一個擴展性的解決方案,同時也很好的解決了一個字段海量數(shù)據(jù)的問題。將方案一中的關(guān)注和被關(guān)注者表分解成兩張表,如下:
表名 |
關(guān)注者表 |
||
字段名 |
字段代碼 |
字段類型 |
描述 |
編號 |
Id |
Number |
主鍵 |
用戶名 |
User_id |
Varchar(20) |
|
關(guān)注者編號 |
Funs_id |
Varchar(20) |
|
表名 |
被關(guān)注者表 |
||
字段名 |
字段代碼 |
字段類型 |
描述 |
編號 |
Id |
Number |
主鍵 |
用戶名 |
User_id |
Varchar(20) |
|
被關(guān)注者編號 |
Wasfuns_id |
Varchar(20) |
|
我看到這樣的設(shè)計我很吃驚,試想一下,假如我一個用戶對應(yīng)有1W個關(guān)注者,那么該用戶就會在關(guān)注者表中存在一萬條他的記錄,這難道不是嚴(yán)重的數(shù)據(jù)冗余嗎?這甚至不符合數(shù)據(jù)庫的設(shè)計規(guī)范。但是事實上證明,這種設(shè)計對大數(shù)據(jù)量的擴展是很不錯的,既然如此,那假如用戶和用戶之間的關(guān)系不只是限于關(guān)注和被關(guān)注的關(guān)系,是不是又要新增表?
解決方案三:
話說“合久必分,分久必合”,對上述的設(shè)計再進一步修改,于是將方案二的兩張表又合二為一,如下:
表名 |
關(guān)注和被關(guān)注者表 |
||
字段名 |
字段代碼 |
字段類型 |
描述 |
編號 |
Id |
Int |
主鍵 |
用戶名 |
User_id |
Varchar(20) |
|
目標(biāo)對象 |
Operate_object |
Varchar(20) |
|
狀態(tài) |
Status |
Number |
當(dāng)目標(biāo)對象為關(guān)注者,標(biāo)示為1; 當(dāng)目標(biāo)對象為被關(guān)注者,標(biāo)示為2; 當(dāng)雙方互相關(guān)注,標(biāo)示為3; 當(dāng)目標(biāo)對象為OO,標(biāo)示為XX。 |
OK,這樣的設(shè)計不僅解決了相當(dāng)一部分的數(shù)據(jù)冗余,而且還能表示用戶之間的多種關(guān)系,方便系統(tǒng)日后的擴展。但是問題又出來了,很明顯這樣設(shè)計對狀態(tài)的維護也是存在疑問的,用一張表代替多張表,數(shù)據(jù)肯定是成倍的增長,是否不符合當(dāng)前常說的“拆庫拆表”的戰(zhàn)略方針(好像這樣的狀態(tài)一般用于“標(biāo)記男女”或者“是否刪除了”之類的,貌似用于這種場合比較的少)。
在上述用戶關(guān)系的解決方案中,可以很簡單的歸結(jié)為就是一對多,多對一,多對多的關(guān)系嘛,那么究竟如何設(shè)計,究竟哪種更好,我很難理解,期待大家拍磚!
posted on 2010-07-19 19:23 kalman03 閱讀(8269) 評論(13) 編輯 收藏 所屬分類: 數(shù)據(jù)庫