题目：一个简单的论坛系统，以数据库储存如下数据：
用户名，email，主页，电话，联系地址，发帖标题，发帖内容，回复标题，回复内容。
每天论坛访问量300万左右，更新帖子10万左右。
请给出数据库表结构设计，并结合范式简要说明设计思路。
下面是我的试答，大家尽管拍砖啊！
试答：
首先经常变动的数据不能和相对稳定的数据放在同一张表。本题中用户名、emial、主页、电话、联系地址属于相对稳定数据（用户不会没事天天登录论坛改email、电话吧？）。其他关于发帖和回帖的数据都属于经常变动的数据。
另外每天帖子更新10万左右，访问量却有300万左右，可以看出很多人“只看帖（或者回帖）但很少发帖”。但是用户看了某个帖子他不一定要回帖，然而隐含一个需求：必须记录每一个发帖的访问量（我觉得没必要记录该发帖具体有哪些用户访问过）。
所以我大概是这样设计表结构的：（4张表）
用户信息表： user
字段名 数据类型 是否允许为空 键属性
uid INT N 主键
uname VARCHAR N
homepageVARCHAR Y
phone VARCHAR Y
address VARCHAR Y
发帖信息表：post
字段名 数据类型 是否允许为空 键属性
pid INT N 主键
title VARCHAR N
content VARCHAR N
uid(发帖者ID)INT N 外键
发帖访问情况表：visit
字段名 数据类型 是否允许为空 键属性
vid INT N 主键
pid INT N 外键
num(浏览数量)INT N
回帖信息表：reply
字段名 数据类型 是否允许为空 键属性
rid INT N 主键
title VARCHAR N
content VARCHAR N
uid INT N 外键
pid INT N 外键
数据库第一范式就不用说了，实体中的某个属性不能有多个值或者不能有重复的属性。这个很容易满足。
再看第二范式，属性必须完全依赖主键。所以发帖和回帖应该设计为在不同的表，因为回帖内容和发帖内容显然依赖于完全不同的主键，其他的类似。即第二范式在这里影响了分几张表。
第三范式是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。按我的理解是，每张表应该尽可能的“干净”，即用户信息表就存与用户最相关的信息，而不能把帖子信息信息也存到里面去。
回帖和发帖信息表中都有一个外键uid来标识回帖或发帖的作者，这就足够了，你不必再把uname也存到里面去，因为uname可以根据uid从user表中查到。当然有时为了性能需要，可能违背数据库设计三范式，比如违背第三范式的字段冗余约束。
有一个地方我觉得肯定另有玄机，“每天帖子更新10万左右，访问量却有300万左右”，这个比例是1:30，具体什么也说不清楚，还望大家多多讨论，指点迷津
------解决方案--------------------
告诉访问量是另有玄机？
------解决方案--------------------
个人感觉哈，没做过打项目，所以是小站经验
需要再多个表，就是一个是标题表（我这么叫它）:包括标题，作者，版块，加精，发表和恢复时间。这个表是不能有content和回复的内容。用来做论坛一级页面的访问表。这样会增加冗余和并且可能和你说的范式冲突。但...这个绝对需要的。天涯，猫扑他们肯定都有（也是我个人感觉哈）
每天十万贴...真多。如果考虑查询速度，我感觉表还要分类，不论用字母还是用用户，形成二级表。否则多了查询速度肯定变慢的
------解决方案--------------------
功能是实现了，但是。。。。。。。
1）你的几张表中没有把记录访问量的表单独列出，这个属性怎么表示呢？除非把其集成到user表中。
2）人家可以匿名的（尽管这个题目没有显示的给出），你怎么表示？
3）user登陆既不发帖也不回帖你怎么存储这个user的在线时间（上线和下线时间------有可能每天重复几次的）
呢？
4）既然访问量和发帖量的相差这么大？为什么不把访问量单独弄个表，而帖子更新（发帖表和回帖表）放在一个
表呢？
------解决方案--------------------
你写的访问信息的内容直接并入到标题表中
------解决方案--------------------
你这个实在做性能优化。。。题目要求“给出数据库表结构设计，并结合范式简要说明设计思路。”可以不做考虑的
------解决方案--------------------
难啊，学习
------解决方案--------------------
每天300w 肯定得分表了否则几天数据就上亿了
我觉得玄机就在这里
感觉 应该按照时间 水平分表一个月 一张表吧
另外 做读写分离
------解决方案--------------------
为id号发帖内容 回帖内容很少做更改 只有写入的
而且这个对数据的一致性要求不高
错几个帖子是完全可以接受的
基本可以不用数据库来处理
------解决方案--------------------
超出了我的能力范围呀！！！
------解决方案--------------------
Post表和Visit表合并，无分开的必要。
每天更新10万的量，意味着reply的主键不能使用INT型。应该用GUID，不知道这个每天更新10万是指算上回帖的量还是纯粹的新贴量，如果是新贴量Post表的主键也不能用INT型
------解决方案--------------------
------解决方案--------------------
：一个简单的论坛系统，以数据库储存如下数据：
用户名，email，主页，电话，联系地址，发帖标题，发帖内容，回复标题，回复内容。
每天论坛访问量300万左右，更新帖子10万
------解决方案--------------------
刚刚学会数据库。看不懂
------解决方案--------------------
首先经常变动的数据不能和相对稳定的数据放在同一张表。本题中用户名、emial、主页、电话、联系地址属于相对稳定数据（用户不会没事天天登录论坛改email、电话吧？）。其他关于发帖和回帖的数据都属于经常变动的数据。
另外每天帖子更新10万左右，访问量却有300万左右，可以看出很多人“只看帖（或者回帖）但很少发帖”。但是用户看了某个帖子他不一定要回帖，然而隐含一个需求：必须记录每一个发帖的访问量（我觉得没必要记录该发帖具体有哪些用户访问过）。
------解决方案--------------------
首先，100W的访问量，一台DB服务器撑不住的，所以你需要做的事情是读写分离，一台DB负责数据增，删，改作为源头DB服务器。放几台DB作为订阅端DB服务器负责查询，根据他上面给出的条件，一天更新10W条数据源头的DB还是可以撑住的，如果条件允许，还可以用分布式缓存，这样可以近一步减低DB的压力。对于帖子来讲，可以考虑水平拆分数据，如一个月为期限，或者按照板块等方式做多个表。不过按时间分表比较合理。
------解决方案--------------------
学习了
------解决方案--------------------
顶你。 复杂嵌套数据表设计 就是偶的弱项。。
------解决方案--------------------
300万不是访问量吗？每天10万才是读写量。新手，勿喷
------解决方案--------------------
共同学习。
------解决方案--------------------
有玄机啊 ，应该按时间分表。
------解决方案--------------------