.net实现的蜘蛛爬虫,实现多线程,实现正则表达式,还差ThreadPool
出去两天，修整一下，有事电话
1
2007/05/01 
19:32 
3340
题目如下
一个简单的论坛系统，以数据库储存如下数据：
用户名，email，主页，电话，联系地址，发帖标题，发帖内容，回复标题，回复内容。
每天论坛访问量300万左右，更新帖子10万左右。
请给出数据库表结构设计，并结合范式简要说明设计思路。
一般的简单的论坛系统，可能我们根本不会考虑到数据库性能，就像简单的设计为如下：
设计三个数据表：userInfo,userTitle,userReplyTitle;结构如下：
userInfo: userName,email,homePage,phone,address. 存储用户基本信息
userTitle: userName,title,context. 存储发帖信息
userReplyTitle: userName,rtitle,rcontext. 存储回复信息
分析：首先userName与其他数据项都有联系，
其次（title,context）（email,homePage,phone,address）（rtitle,rcontext）这三组数据互相没有联系。
分成三个表不会造成传递依赖，三个表以userName连接查找。这样的设计是符合第三范式的。
其实Baidu的意图很明显，访问量300w，更新10w，这是一个很大的数据量，所以BAIDU的意图应该是要数据库尽量的优化。从我个人的角度看起码有如下几个问题没有考虑到：
1：应该使用一个ID为Int的类型来关联，而不是Username2：没有建立索引信息
3：对与更新量这么大，UserInfo中应该保存一个UserName信息
第二道题，用户和发贴是一对多的，帖子和回复又是一对多的。
还有，最好表的内键和外键不要和数据参合在一块儿，各单独建个ID字段就可以了。
这是一个朋友的回复，我觉得说的非常好：
第2题暴露了你没有设计大流量论坛系统底层的经验，首先是表结构问题，其实是关系的效率问题，用userName这种char类型字段来关联table会让你种设计慢如虫爬。
考虑这样：
userInfo: userId,userName,email,homePage,phone,address. 存储用户基本信息
userTitle: titleID,userId,userName,title,context,isTopic. 存储发帖/回帖信息,主题帖的isTopic为NULL,回帖的isTopic为主题帖ID
为什么不把userName做为关联内容，而要在userTitle表中也放一个userName呢，因这样可以令读取帖子列表及帖子内容时只读userTitle表而不用inner join，只有点击查看用户资料时才取userInfo表。效率第一，牺牲几个字节存放userName，是可以的吧
当然他说的也不是最好的
我想应该继续深入学习一下数据库的理论知识。到使用的时候才发现知识是少的
引用
一个简单的论坛系统，以数据库储存如下数据：
用户名，email，主页，电话，联系地址，发帖标题，发帖内容，回复标题，回复内容。
每天论坛访问量300万左右，更新帖子10万左右。
请给出数据库表结构设计，并结合范式简要说明设计思路。
一般的简单的论坛系统，可能我们根本不会考虑到数据库性能，就像简单的设计为如下：
引用
设计三个数据表：userInfo,userTitle,userReplyTitle;结构如下：
userInfo: userName,email,homePage,phone,address. 存储用户基本信息
userTitle: userName,title,context. 存储发帖信息
userReplyTitle: userName,rtitle,rcontext. 存储回复信息
分析：首先userName与其他数据项都有联系，
其次（title,context）（email,homePage,phone,address）（rtitle,rcontext）这三组数据互相没有联系。
分成三个表不会造成传递依赖，三个表以userName连接查找。这样的设计是符合第三范式的。
其实Baidu的意图很明显，访问量300w，更新10w，这是一个很大的数据量，所以BAIDU的意图应该是要数据库尽量的优化。从我个人的角度看起码有如下几个问题没有考虑到：
1：应该使用一个ID为Int的类型来关联，而不是Username2：没有建立索引信息
3：对与更新量这么大，UserInfo中应该保存一个UserName信息
引用
第二道题，用户和发贴是一对多的，帖子和回复又是一对多的。
还有，最好表的内键和外键不要和数据参合在一块儿，各单独建个ID字段就可以了。
这是一个朋友的回复，我觉得说的非常好：
引用
第2题暴露了你没有设计大流量论坛系统底层的经验，首先是表结构问题，其实是关系的效率问题，用userName这种char类型字段来关联table会让你种设计慢如虫爬。
考虑这样：
userInfo: userId,userName,email,homePage,phone,address. 存储用户基本信息
userTitle: titleID,userId,userName,title,context,isTopic. 存储发帖/回帖信息,主题帖的isTopic为NULL,回帖的isTopic为主题帖ID
为什么不把userName做为关联内容，而要在userTitle表中也放一个userName呢，因这样可以令读取帖子列表及帖子内容时只读userTitle表而不用inner join，只有点击查看用户资料时才取userInfo表。效率第一，牺牲几个字节存放userName，是可以的吧
当然他说的也不是最好的
我想应该继续深入学习一下数据库的理论知识。到使用的时候才发现知识是少的
fisher
2008/10/01 21:10
title 表里面耦合username似乎连第二范式都不符合……
其实成熟的关系数据库不会因为一个join就慢得不得了，并不是每一次命中都会发生磁盘读写的，想想看一个用于300w访问量，10w新贴的论坛，他的数据库服务器会是什么样的？？我想最保守估计，即使是单一数据库服务器也会拥有4gb内存吧，甚至应该使用群集服务器的。这样看来，这4gb内存可以干很多事情……
一个论坛系统，user的数量远远少于article数量，而对user的检索确远多于对title表。这样看来，聪明的数据库会缓存很大一部分user表中的信息。
从另一个角度讲，你耦合上一个username之后，或许会略微的提高article的select效率，但是当username发生变更时，却是引发了2次写操作。这要比发生10次读取更加浪费时间。
说了这么多。。。想说的就是一点，现在关系数据库，不需要你考虑那么多，按照范式中说阐述的原理构建就可以了。只要不出现严重的设计缺陷，性能问题最好的解决办法就是对服务器硬件的升级，要知道相对于其他产品来说x86架构的服务器是非常非常廉价的……
其实成熟的关系数据库不会因为一个join就慢得不得了，并不是每一次命中都会发生磁盘读写的，想想看一个用于300w访问量，10w新贴的论坛，他的数据库服务器会是什么样的？？我想最保守估计，即使是单一数据库服务器也会拥有4gb内存吧，甚至应该使用群集服务器的。这样看来，这4gb内存可以干很多事情……
一个论坛系统，user的数量远远少于article数量，而对user的检索确远多于对title表。这样看来，聪明的数据库会缓存很大一部分user表中的信息。
从另一个角度讲，你耦合上一个username之后，或许会略微的提高article的select效率，但是当username发生变更时，却是引发了2次写操作。这要比发生10次读取更加浪费时间。
说了这么多。。。想说的就是一点，现在关系数据库，不需要你考虑那么多，按照范式中说阐述的原理构建就可以了。只要不出现严重的设计缺陷，性能问题最好的解决办法就是对服务器硬件的升级，要知道相对于其他产品来说x86架构的服务器是非常非常廉价的……
分页： 1/1 
1 
1
