百度筆試題--論壇資料庫表設計
轉載地址:http://blog.sina.com.cn/s/blog_542a862901000cbq.html
二、 一個簡單的論壇系統,以資料庫儲存如下資料:
使用者名稱,email,主頁,電話,聯絡地址,發帖標題,發帖內容,回覆標題,回覆內容。
每天論壇訪問量300萬左右,更新帖子10萬左右。
請給出資料庫表結構設計,並結合正規化簡要說明設計思路。
簡評:
這道題也與百度的業務有關,百度現在除了搜尋外,還有貼吧,知道,部落格等重要產品。
同時也在積極的探索社群化,包括前不久宣佈進軍電子商務領域,搜尋之外的這些產品, 其主要功能的實現主要是對資料庫的操作。
因此,想進入百度,也需要對資料庫有一定的認識。
實現思路及資料庫設計:
1,該論壇主要有兩個實體物件,使用者和帖子;對於帖子物件,有一個問題:回覆的帖子是否應該跟主題帖子存放在同一個表裡?
考慮到每天更新10萬帖子,說明帖子數比較多,為了方便主題的呈現,我一般都把主題貼和回帖分別放在不同的表中,把主題貼和回帖分開可以提高查詢效率(300萬的訪問量每天)。
2,按照1中的思路,該論壇由兩個物件(使用者和帖子)變成三個實體物件,分別是使用者,主題帖子,回覆帖子;
3,上述三個物件存在三個關係,分別是:
使用者--主題帖,一個使用者可以發0個或多個帖子,一個帖子對應一個使用者(一對多關係),
主題帖--回覆帖:一個主題有0個或多個回覆帖子,一個回覆帖子對應一個主題(一對多關係);
使用者--回覆貼:一個使用者可以回0個或多個帖,一個帖子對應一個使用者(一對多關係)。
還存在對回覆貼的回覆,這個考慮用fatherId來表示。
4,由於三個關係 “使用者--主題帖,主題帖--回覆帖,使用者--回覆貼” 都是一對多關係,根據表設計一般原則,可以將這兩個關係獨立建立表,也可以不另外建表而將一對多的關係體現在實體表中;然而,表間的連線查詢是非常耗資源的,所以應儘量減少表間連線,那麼對三個關係不應該分別建表,而是把使用者的id作為主題表和回帖表的外來鍵,把主題貼id作為回帖表的外來鍵。
5,鑑於以上考慮,該論壇的三個表如下所示
表名:t_user_info (使用者資訊表)
欄位名 | 型別 | 預設值 | 中文含義 | 約束 | 備註 |
id | Int | 使用者編號 | PRI | Auto_increment | |
Name | Varchar(30) | 使用者名稱 | |||
Varchar(50) | |||||
Phone | Varchar(30) | ||||
Addr | Varchar(200) |
其他欄位略,根據需要新增
表名:main_content_info (主題帖資訊表)
欄位名 | 型別 | 預設值 | 中文含義 | 約束 | 備註 |
id | Int | 貼編號 | PRI | Auto_increment | |
Title | Varchar(200) | 發帖標題 | |||
Content | Text | 發帖內容 | |||
UserID | Int | 使用者編號 | 外來鍵 |
其他欄位略,根據需要新增
表名:sub_content_info (回覆貼資訊表)
欄位名 | 型別 | 預設值 | 中文含義 | 約束 | 備註 |
id | Int | 貼編號 | PRI | Auto_increment | |
Title | Varchar(200) | 發帖標題 | |||
Content | Text | 發帖內容 | |||
UserID | Int | 使用者編號 | 外來鍵 | ||
FatherID | Int | 父編號 | |||
MainID | Int | 主題帖編號 | 外來鍵 |
其他欄位略,根據需要新增
6,符合正規化分析:
上述表中每個欄位不可再分,首先滿足1NF;
然後資料庫表中的每個例項或行都是可以被惟一地區分(id),不存在部分依賴,因此滿足2NF;
t_user_info (使用者資訊表)和main_content_info (主題帖資訊表)不存在任何傳遞依賴,至少屬於BCNF;
但是sub_content_info (回覆貼資訊表)不滿足3NF,因為存二、 一個簡單的論壇系統,以資料庫儲存如下資料:
使用者名稱,email,主頁,電話,聯絡地址,發帖標題,發帖內容,回覆標題,回覆內容。
每天論壇訪問量300萬左右,更新帖子10萬左右。
請給出資料庫表結構設計,並結合正規化簡要說明設計思路。
簡評:
這道題也與百度的業務有關,百度現在除了搜尋外,還有貼吧,知道,部落格等重要產品。
同時也在積極的探索社群化,包括前不久宣佈進軍電子商務領域,搜尋之外的這些產品,
其主要功能的實現主要是對資料庫的操作。
因此,想進入百度,也需要對資料庫有一定的認識。
實現思路及資料庫設計:
1,該論壇主要有兩個實體物件,使用者和帖子;對於帖子物件,有一個問題:回覆的帖子是否應該跟主題帖子存放在同一個表裡?
考慮到每天更新10萬帖子,說明帖子數比較多,為了方便主題的呈現,我一般都把主題貼和回帖分別放在不同的表中,把主題貼和回帖分開可以提高查詢效率(300萬的訪問量每天)。
2,按照1中的思路,該論壇由兩個物件(使用者和帖子)變成三個實體物件,分別是使用者,主題帖子,回覆帖子;
3,上述三個物件存在三個關係,分別是:
使用者--主題帖,一個使用者可以發0個或多個帖子,一個帖子對應一個使用者(一對多關係),
主題帖--回覆帖:一個主題有0個或多個回覆帖子,一個回覆帖子對應一個主題(一對多關係);
使用者--回覆貼:一個使用者可以回0個或多個帖,一個帖子對應一個使用者(一對多關係)。
還存在對回覆貼的回覆,這個考慮用fatherId來表示。
4,由於三個關係 “使用者--主題帖,主題帖--回覆帖,使用者--回覆貼” 都是一對多關係,根據表設計一般原則,可以將這兩個關係獨立建立表,也可以不另外建表而將一對多的關係體現在實體表中;然而,表間的連線查詢是非常耗資源的,所以應儘量減少表間連線,那麼對三個關係不應該分別建表,而是把使用者的id作為主題表和回帖表的外來鍵,把主題貼id作為回帖表的外來鍵。
5,鑑於以上考慮,該論壇的三個表如下所示
表名:t_user_info (使用者資訊表)
欄位名 型別 預設值 中文含義 約束 備註
id Int 使用者編號 PRI Auto_increment
Name Varchar(30) 使用者名稱
Email Varchar(50)
Phone Varchar(30)
Addr Varchar(200)
其他欄位略,根據需要新增
表名:main_content_info (主題帖資訊表)
欄位名 型別 預設值 中文含義 約束 備註
id Int 貼編號 PRI Auto_increment
Title Varchar(200) 發帖標題
Content Text 發帖內容
UserID Int 使用者編號 外來鍵
其他欄位略,根據需要新增
表名:sub_content_info (回覆貼資訊表)
欄位名 型別 預設值 中文含義 約束 備註
id Int 貼編號 PRI Auto_increment
Title Varchar(200) 發帖標題
Content Text 發帖內容
UserID Int 使用者編號 外來鍵
FatherID Int 父編號
MainID Int 主題帖編號 外來鍵
其他欄位略,根據需要新增
6,符合正規化分析:
上述表中每個欄位不可再分,首先滿足1NF;
然後資料庫表中的每個例項或行都是可以被惟一地區分(id),不存在部分依賴,因此滿足2NF;
t_user_info (使用者資訊表)和main_content_info (主題帖資訊表)不存在任何傳遞依賴,至少屬於BCNF;
但是sub_content_info (回覆貼資訊表)不滿足3NF,因為存在如下傳遞依賴:id-->FatherID,FatherID-->MainID。
正規化並不是越高越好,sub_content_info表只滿足2NF卻更有效率,也是當今論壇較主流的設計。在如下傳遞依賴:id-->FatherID,FatherID-->MainID。
正規化並不是越高越好,sub_content_info表只滿足2NF卻更有效率,也是當今論壇較主流的設計。