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

转载地址: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却更有效率,也是当今论坛较主流的设计。


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页