转自：http://blog.csdn.net/yuan22003/article/details/6747979
一个简单的论坛系统，以数据库储存如下数据：
用户名，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却更有效率，也是当今论坛较主流的设计。