轉載地址：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 (使用者資訊表)

　　其他欄位略，根據需要新增

　　表名：main_content_info (主題帖資訊表)

　　其他欄位略，根據需要新增

 表名：sub_content_info (回覆貼資訊表)

　　其他欄位略，根據需要新增

　　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卻更有效率，也是當今論壇較主流的設計。