kalman03

          每天早上看一遍《福布斯》富翁排行榜,如果上面沒有我的名字,我就去學(xué)習(xí)......
          隨筆 - 22, 文章 - 0, 評論 - 86, 引用 - 0
          數(shù)據(jù)加載中……

          一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考

                 在微博系統(tǒng)中,當(dāng)前用戶、關(guān)注者(也就是粉絲)、被關(guān)注者(崇拜對象)這三種角色是少不了的。他們之間看似簡單的關(guān)系,但是其中數(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)注者BCDE,那么存入數(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ù)庫

          評論

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          我認(rèn)為方案二是最清晰的
          2010-07-20 09:31 | cxh8318

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          方案3, 以后可以根據(jù)狀態(tài)做分區(qū)或者路由.
          2010-07-20 09:48 | dead_lee

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          為什么不是這樣呢
          create user (
          user_id varchar(20) primary key,
          password varchar(160)
          );
          create watches (
          id int primary key,
          watcher varchar(20),
          watchee varcher(20)
          );
          2010-07-20 09:54 | anon

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考[未登錄]  回復(fù)  更多評論   

          用戶表,用戶-崇拜對象表,用戶-粉絲視圖

          需要關(guān)注的是后兩者的數(shù)據(jù)量
          2010-07-20 10:16 | Wade

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          我認(rèn)為這三個方案的優(yōu)劣順序為 2>1>3, 3會讓處理邏輯變得非常復(fù)雜,其實方案2應(yīng)該只要一個表就可以了,fans表,因為關(guān)注和被關(guān)注是互逆的,查不同列就可以了,這樣的關(guān)系表最能體現(xiàn)數(shù)據(jù)庫管理數(shù)據(jù)的長處。
          2010-07-20 15:21 | HiMagic!

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          很想知道sina圍脖的庫是怎么設(shè)計的,有知道的分享一下。
          2010-07-21 10:57 | Robin's Java World

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          @Robin's Java World
          我也很想知道
          2010-07-22 11:44 | kalman03

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          贊同@anon
          2010-07-26 16:15 | watcher

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          不知道為什么這么多人說方案2好
          2011-04-08 13:15 | dohkoos

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          寫錯了,沒看清。
          如同HiMagic!和anon講的,其實方案2只要一張表就可以了
          create users (
          user_id varchar(20) primary key,
          password varchar(160)
          );
          create watches (
          id int primary key,
          watcher varchar(20),
          watchee varcher(20)
          );

          方案3是根本看不懂,不知道Operate_object這個是什么東西
          2011-04-08 13:19 | dohkoos

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考[未登錄]  回復(fù)  更多評論   

          可不可以這樣呢,讓數(shù)據(jù)適當(dāng)?shù)娜哂嘞拢?br>
          user
          {
          user_id,
          user_pwd,
          ……
          fansid,
          followersid
          }

          relationship --這個是互逆的
          {
          id,
          uid,
          fanid
          }
          2011-06-28 17:32 | shine

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考[未登錄]  回復(fù)  更多評論   

          方案2較好

          一個用戶,不會去關(guān)注數(shù)以萬計的人。。。實踐證明,有幾千,已經(jīng)很很大了。

          但一個用戶,可能被數(shù)千萬人關(guān)注,這個是重點要解決的數(shù)據(jù)膨脹。這個容易實現(xiàn)水平分割。
          2012-03-01 10:25 | allen

          # re: 一個微博數(shù)據(jù)庫設(shè)計帶來的簡單思考  回復(fù)  更多評論   

          @anon
          比較贊成這種方式!第一種數(shù)據(jù)冗余,在數(shù)據(jù)量大時,關(guān)系變更時操作復(fù)雜。第三種方案同樣的邏輯,關(guān)系變更時操作復(fù)雜!
          2016-02-17 13:50 | ManKane
          主站蜘蛛池模板: 韶山市| 河北省| 河南省| 卫辉市| 彰武县| 慈利县| 白河县| 新和县| 吉水县| 确山县| 泰安市| 县级市| 新田县| 阿拉善盟| 泽库县| 广昌县| 泾川县| 新野县| 贵德县| 周宁县| 泸定县| 启东市| 余庆县| 西和县| 榆社县| 仙桃市| 日喀则市| 曲阜市| 彭山县| 佛坪县| 海伦市| 双鸭山市| 周口市| 沅江市| 平南县| 定南县| 阿拉善左旗| 宝丰县| 黄浦区| 油尖旺区| 富宁县|