读书人

一道百度面试题试答(数据库表设计)

发布时间: 2012-02-12 17:16:33 作者: rapoo

一道百度面试题试答(数据库表设计),欢迎大家拍砖!
题目:一个简单的论坛系统,以数据库储存如下数据:

用户名,email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容。

每天论坛访问量300万左右,更新帖子10万左右。

请给出数据库表结构设计,并结合范式简要说明设计思路。

下面是我的试答,大家尽管拍砖啊!
试答:
首先经常变动的数据不能和相对稳定的数据放在同一张表。本题中用户名、emial、主页、电话、联系地址属于相对稳定数据(用户不会没事天天登录论坛改email、电话吧?)。其他关于发帖和回帖的数据都属于经常变动的数据。
另外每天帖子更新10万左右,访问量却有300万左右,可以看出很多人“只看帖(或者回帖)但很少发帖”。但是用户看了某个帖子他不一定要回帖,然而隐含一个需求:必须记录每一个发帖的访问量(我觉得没必要记录该发帖具体有哪些用户访问过)。
所以我大概是这样设计表结构的:(4张表)

用户信息表: user
字段名数据类型是否允许为空键属性
uidINT N 主键
unameVARCHAR N
homepageVARCHAR Y
phoneVARCHAR Y
addressVARCHAR Y

发帖信息表:post
字段名数据类型是否允许为空键属性
pid INTN 主键
title VARCHARN
content VARCHARN
uid(发帖者ID)INTN 外键

发帖访问情况表:visit
字段名数据类型是否允许为空键属性
vid INTN 主键
pid INTN 外键
num(浏览数量)INTN

回帖信息表:reply
字段名数据类型是否允许为空键属性
ridINT N 主键
titleVARCHAR N
contentVARCHAR N
uidINT N 外键
pidINT N 外键

数据库第一范式就不用说了,实体中的某个属性不能有多个值或者不能有重复的属性。这个很容易满足。
再看第二范式,属性必须完全依赖主键。所以发帖和回帖应该设计为在不同的表,因为回帖内容和发帖内容显然依赖于完全不同的主键,其他的类似。即第二范式在这里影响了分几张表。
第三范式是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。按我的理解是,每张表应该尽可能的“干净”,即用户信息表就存与用户最相关的信息,而不能把帖子信息信息也存到里面去。
回帖和发帖信息表中都有一个外键uid来标识回帖或发帖的作者,这就足够了,你不必再把uname也存到里面去,因为uname可以根据uid从user表中查到。当然有时为了性能需要,可能违背数据库设计三范式,比如违背第三范式的字段冗余约束。

有一个地方我觉得肯定另有玄机,“每天帖子更新10万左右,访问量却有300万左右”,这个比例是1:30,具体什么也说不清楚,还望大家多多讨论,指点迷津





[解决办法]
告诉访问量是另有玄机?
[解决办法]
个人感觉哈,没做过打项目,所以是小站经验
需要再多个表,就是一个是标题表(我这么叫它):包括标题,作者,版块,加精,发表和恢复时间。这个表是不能有content和回复的内容。用来做论坛一级页面的访问表。这样会增加冗余和并且可能和你说的范式冲突。但...这个绝对需要的。天涯,猫扑他们肯定都有(也是我个人感觉哈)
每天十万贴...真多。如果考虑查询速度,我感觉表还要分类,不论用字母还是用用户,形成二级表。否则多了查询速度肯定变慢的
[解决办法]
功能是实现了,但是。。。。。。。

1)你的几张表中没有把记录访问量的表单独列出,这个属性怎么表示呢?除非把其集成到user表中。
2)人家可以匿名的(尽管这个题目没有显示的给出),你怎么表示?
3)user登陆既不发帖也不回帖你怎么存储这个user的在线时间(上线和下线时间------有可能每天重复几次的)
呢?
4)既然访问量和发帖量的相差这么大?为什么不把访问量单独弄个表,而帖子更新(发帖表和回帖表)放在一个
表呢?
[解决办法]
你写的访问信息的内容直接并入到标题表中
[解决办法]

探讨

个人感觉哈,没做过打项目,所以是小站经验
需要再多个表,就是一个是标题表(我这么叫它):包括标题,作者,版块,加精,发表和恢复时间。这个表是不能有content和回复的内容。用来做论坛一级页面的访问表。这样会增加冗余和并且可能和你说的范式冲突。但...这个绝对需要的。天涯,猫扑他们肯定都有(也是我个人感觉哈)
每天十万贴...真多。如果考虑查询速度,我感觉表还要分类,不论用字母还是用用户,形……

[解决办法]
难啊,学习
[解决办法]
每天300w 肯定得分表了否则几天数据就上亿了

我觉得玄机就在这里

感觉 应该按照时间 水平分表一个月 一张表吧


另外 做读写分离

[解决办法]
为id号发帖内容 回帖内容很少做更改 只有写入的

而且这个对数据的一致性要求不高

错几个帖子是完全可以接受的

基本可以不用数据库来处理


[解决办法]
超出了我的能力范围呀!!!
[解决办法]
Post表和Visit表合并,无分开的必要。

每天更新10万的量,意味着reply的主键不能使用INT型。应该用GUID,不知道这个每天更新10万是指算上回帖的量还是纯粹的新贴量,如果是新贴量Post表的主键也不能用INT型
[解决办法]
learning......
------解决方案--------------------


:一个简单的论坛系统,以数据库储存如下数据:

用户名,email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容。

每天论坛访问量300万左右,更新帖子10万
[解决办法]
刚刚学会数据库。看不懂
[解决办法]
首先经常变动的数据不能和相对稳定的数据放在同一张表。本题中用户名、emial、主页、电话、联系地址属于相对稳定数据(用户不会没事天天登录论坛改email、电话吧?)。其他关于发帖和回帖的数据都属于经常变动的数据。
另外每天帖子更新10万左右,访问量却有300万左右,可以看出很多人“只看帖(或者回帖)但很少发帖”。但是用户看了某个帖子他不一定要回帖,然而隐含一个需求:必须记录每一个发帖的访问量(我觉得没必要记录该发帖具体有哪些用户访问过)。

[解决办法]
首先,100W的访问量,一—B服务器撑不住的,所以你需要做的事情是读写分离,一—B负责数据增,删,改作为源头DB服务器。放几—B作为订阅端DB服务器负责查询,根据他上面给出的条件,一天更新10W条数据源头的DB还是可以撑住的,如果条件允许,还可以用分布式缓存,这样可以近一步减低DB的压力。对于帖子来讲,可以考虑水平拆分数据,如一个月为期限,或者按照板块等方式做多个表。不过按时间分表比较合理。
[解决办法]

学习了

[解决办法]
顶你。 复杂嵌套数据表设计 就是偶的弱项。。
[解决办法]
300万不是访问量吗?每天10万才是读写量。新手,勿喷
[解决办法]
共同学习。
[解决办法]
有玄机啊 ,应该按时间分表。
[解决办法]
学习了,楼主很厉害啊。
[解决办法]
只需要三个表


用户信息表: user
字段名 数据类型 是否允许为空 键属性
uid INT N 主键
uname VARCHAR N
homepageVARCHAR Y
phone VARCHAR Y
address VARCHAR Y

发帖信息表:post
字段名 数据类型 是否允许为空 键属性
uid(发帖者ID)INT N 外键
title VARCHAR N 外键
content VARCHAR N
num(浏览数量)INT N
两个外键和起来作主键

回帖信息表:reply
字段名 数据类型 是否允许为空 键属性
uid INT N 外键
title VARCHAR N 外键
content VARCHAR N

两个外键和起来作主键
[解决办法]
学习了 数据库 不熟
[解决办法]
度有
[解决办法]

探讨
只需要三个表


用户信息表: user
字段名 数据类型 是否允许为空 键属性
uid INT N 主键
uname VARCHAR N
homepageVARCHAR Y
phone VARCHAR Y
address VARCHAR Y

发帖信息表:post
字段名 数据类型 是否允许为空 键属性
uid(发帖者ID)INT N 外键
title VAR……

[解决办法]
事天天登录论坛改email、电话吧?)。其他关于发帖和回帖的数据都属于经常变动的数据。
另外每天帖子更新10万左右,访问量却有300万左右,可以看出很多人“只看帖(或者回帖)但很少发帖”。但是用户看了某个帖子他不一定要回帖,然而隐含一个需求:必须记录每一个发帖的访问量(我觉得没必要记录该发帖具体有哪些用户访问过)。

[解决办法]
探讨

引用:

个人感觉哈,没做过打项目,所以是小站经验
需要再多个表,就是一个是标题表(我这么叫它):包括标题,作者,版块,加精,发表和恢复时间。这个表是不能有content和回复的内容。用来做论坛一级页面的访问表。这样会增加冗余和并且可能和你说的范式冲突。但...这个绝对需要的。天涯,猫扑他们肯定都有(也是我个人感觉哈)
每天十万贴...真多。如果考虑查询速度,……

[解决办法]
学习了,楼主很厉害啊。
[解决办法]
探讨
引用:
只需要三个表


用户信息表: user
字段名 数据类型 是否允许为空 键属性
uid INT N 主键
uname VARCHAR N
homepageVARCHAR Y
phone VARCHAR Y
address VARCHAR Y

发帖信息表:post
字段名 数据类型 是否允许为空 键属性
uid(发帖者ID……

------解决方案--------------------


看不懂,现在看来数据库还是很深的,好好学吧~~~·
[解决办法]
看完上述回复,表设计上大家意见一致。
分歧则在于,对题目的解读。
如果只回答表面所问的问题,楼主给出的答案足以。

那么,在各位深层次的挖掘下,隐藏的考点又有多少呢? 对此,又应当如何解答呢?
[解决办法]
25 和 29 楼的意见我比较赞成,这个1:30的更新和读的比例,应该是暗示你要做到“读写分离”。呵呵,要不要考虑主---从数据库的模式呢?或者,就在一个库中,有的表只用来读?但和另外一个能更新的表保持同步。呵呵。
[解决办法]
抱着学习的态度
[解决办法]
不知道怎么样,有成功的没
[解决办法]

探讨

只需要三个表


用户信息表: user
字段名 数据类型 是否允许为空 键属性
uid INT N 主键
uname VARCHAR N
homepageVARCHAR Y
phone VARCHAR Y
address VARCHAR Y

发帖信息表:post
字段名 数据类型 是否允许为空 键属性
uid(发帖者ID)INT N 外键
title VA……

[解决办法]
太难了,
[解决办法]
惭愧,不会啊

[解决办法]
最近在研究Caché数据库,学习了
[解决办法]
论坛系统,以数据库储存
[解决办法]
范式123
[解决办法]
果然另有玄机
[解决办法]
1,破除第三范式
2,三张表 USER,SENDPOST,USERSENDPOST.
[解决办法]
还得努力啊。。。
[解决办法]
这个有点难啊,学习
[解决办法]
既然都楼都盖到这份儿上了,也不在乎多盖一个管理权限表吧。
[解决办法]
记得以前我也做过 论坛的小例子 好像当时我设计的是三个表。
[解决办法]
虽然不知道 楼主讲的什么 但是我觉得楼主很厉害!
[解决办法]
可能数据库我不是很多,我觉得,那个访问量是不是说,读取数量远远大于更新数量。所以,考虑建索引的时候应该有特别的考虑。(因为更新索引的耗费有时候会非常大,然后实际情况是更新只有10万,而访问有300万,所以可以适当建立索引会给性能上带来提升吧。)。。。。没什么经验。。
[解决办法]
这个问题问问CSDN的DBA吧!
[解决办法]
这里提示大数据量,很显然是需要考虑到性能问题,一般来说处理性能必然会和数据库范式有一定的冲突,主要在于怎么把握取舍。。
另外最好使用分区表,物化视图等数据库的技术,分区表对查询和更新的性能提升非常大,特别是分区索引的使用,对性能提升非常明显,至于物化视图主要在于查询,不能使用在存在大量更新的表
[解决办法]
个人理解

读写分离
索引
[解决办法]
不错,又学到了一点经验。谢谢喽
[解决办法]
访问300w,提交10万,读的频率是写的30倍,除了强调读写频繁,还强调,读速度比写速度重要。

把用户和email这些要和内容一起读的字段放到帖子和回复所在的表里都可以。跨表查询效率较低。
[解决办法]
建索引

大文本单独建表


[解决办法]
这个问题问问CSDN的DBA吧!
------解决方案--------------------


还行,谢谢啊
[解决办法]
bu cuo
[解决办法]
要学的 太多了

读书人网 >行业软件

热点推荐