百度笔试题--论坛数据库表设计

转载地址：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)		用户名
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,因为存二、 一个简单的论坛系统，以数据库储存如下数据：
　　用户名，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却更有效率，也是当今论坛较主流的设计。