爱心技术专栏专题

基于MySQL的BBS设计1

摘录:SQLServer 来源:SQLServer 加入时间:2007年02月27日
摘要:
基于MySQL的BBS设计1

1。系统架构: 
采用模块化思想,分为3层: 
a。数据存储层:使用mysql来存放bbs的所有数据,包括用户信息, 
文章数据,用户信件,用户消息,系统数据(?),关键问题: 
数据库的规划,是否用文件来辅助。 
b。系统功能层:完成bbs的基本功能,由多个并列模块组成,向下 
调…

转载:转载请保留本信息,本文来自
http://www.51dibs.com
/html/2006/article/info10/a_1528ec67781f3ffa.htm

基于MySQL的BBS设计1

站点:爱心种子小博士 关键字:基于MySQL的BBS设计1

   
基于MySQL的BBS设计1
1。系统架构: 
采用模块化思想,分为3层: 
a。数据存储层:使用mysql来存放bbs的所有数据,包括用户信息, 
文章数据,用户信件,用户消息,系统数据(?),关键问题: 
数据库的规划,是否用文件来辅助。 
b。系统功能层:完成bbs的基本功能,由多个并列模块组成,向下 
调用mysql的函数访问数据库,向上,接受处理请求,将处理的 
结果返回上层,根据请求类型,返回成败结果和其他数据。而且 
模块高度灵活,可以方便的修改增加。包括: 
** 用户模块,处理用户的注册,基本数据的修改,权限的变化, 
网友信息的查询。 
** 版面模块,完成文章发表,文章的读取,文章的删除,文章 
的加标记,读改删权限检查,此模块对数据库的要求最高。 
** 精华区模块,包括精华区的文章,目录的增加,删除,上下移动 
(?)读改删权限检查,目录结构是其中的难点。 
** 信件模块,包括发新信件,读删信件,信笺标记,新信件的通 
知 
** 消息模块,包括发送消息,接受消息,新消息通知,消息回顾, 
消息存信件。 
** 系统动态模块,包括当前上站人数,当前动态,由于变动频繁, 
此类数据用共享内存实现可能更好。 
** 聊天模块,双人聊天是否能借鉴icq的做法,由双方直接通话, 
但聊天结果存信件可能较麻烦,同时,为兼容telnet功能,当 
上层服务层为telnet时,增加专门的模块来进行处理。 
** 聊天室模块,利用共享内存还是数据库?开房间,里面的权限 
问题。 
根据需要,还能增加新的功能。例如:活动看板模块,但对于非 
telnet终端,意义好象不大。。。。。 
c。服务层:直接和客户机对话,根据客户机的请求,调用功能模块取得 
数据,然后将数据发送回客户端,根据客户端的类型,分别开发不同 
的服务模块,并且尽可能合理进行抽象,使对不同的服务层,能共用 
系统功能层的模块。具体包括: 
++ cq66服务端,采取原cq66的方式,并重新规划协议,支持系统功能 
层的所有功能,但要用专门的客户端程序(cq66),如果能做到向 
下兼容则更好,客户端程序要随服务端的升级而升级,用户可能有 
点不便。有需要可以在传输过程中加入加密功能,类似ssh。 
++ telnet服务端,采用旧bbs的方式,有些功能不支持,客户端无须 
升级,服务器端要保存客户方的状态,并根据客户端的按键来判断 
状态的转移,并由此得出所需的数据,(例如阅读某篇文章),然 
后再向系统功能层请求数据,然后将数据加以处理(例如加上顶行, 
尾行)然后返回数据,可以在现有的bbsd上修改,可以省去io模块 
的设计但难度较大,除文章方面好一点外,其他比较难改,但从头 
写起太费力。 
++ httpd服务端,所需的功能更少,相对较简单,本来直接调用mysql 
数据库也行,直接可以用php,但考虑到分层的原则,建议仍用c编 
cgi的方式实现不知能不能在原来的基础上修改呢?估计不行。 
系统的关键和难点: 
a。数据库的设计,mysql支持大量的table吗?例如几万?每个 
用户至少一个表,然后每个版一个表,精华区的表结构可能更复杂。 
但应该总会比现在bbs的文件结构清晰一些,效率也高一点吧,排序 
和cache的功能可以信赖mysql吧。 
b。mysql中文本字段的大小限制,限制一篇文章不得大于64k不过分吧, 
而且从效率的角度,将一篇文章以最大2k的块为单位存放可能更好, 
这样,当telnet用户看文章时,telnet服务器不用每次都查询数据库 
读取几十k的数据,再将其中的某2k传给用户,可局部补偿数据库字段 
不能象文件那样从中间读取一部分。不过这样文章字段数据的管理 
比较复杂。 
2。系统开发计划: 
先考虑用户模块和版面模块,规划好数据结构,应该很容易和现有bbsd结合 
起来的。然后再考虑其他模块?。。。。。。。 
(//以下有空再写。。。。。先睡觉去。。hmm.........) 
3。数据库设计 
4。用户模块设计 
5。版面模块设计 
6。bbsd和cq66服务器端改造 
7。初步测试计划 。 

------------------------------------------------- 
3。数据库设计 
关键还是mysql的效率问题,合理分配mysql的内存,特别是table cache的 
大小。另外,当系统突然掉电呢?mysql是否robust? 
table的名字设计,采用一位前缀表明类型,全部用小写表示(?),例如: 
系统的数据库,以s为前导,如用户表:suser(sUSER 呢?),具体如下: 
s :系统表,suser,sclass 
m :用户信件表,msysop,mdrangon 
w :用户消息表,wsysop,wdrangon 
a :版面索引表,alinux,acampus 
b :版面文章表,blinux,bcampus 
c :特殊分类版面表,cnewboard 
i :精华区索引表,ilinux,ilinux01,icampus,icampus04 
j :精华区文章表,jlinux,jcampus, 

另外,是使用字串还是数字作为标识呢?例如,一个叫sysop的帐号,其 
id是1,他的信的表是msysop还是m00001呢?同样,一个叫campus的版,对应的 
代码是5,则这个版的文章的表名是bcampus还是b00005呢?可能用字串会容易 
理解,查错吧。 

用户信息表:suser 
usernum int unique, // 唯一标识符,最多30000个帐号,会不会太少了? 
userid char[20] primary key, // 排序的关键字,id,全小写。 
passwd char[20], // 密码,存放加密后的密文。 
realid char[20], // 实际id,大小写混合。 
username char[24], // 用户的泥称 
userlevel longint, // 64种权限? 
numlogins int, 
numposts int, 
firstlogin time, 
lastlogin time, 
staytime time, /* 总共停留时间 */ 
lasthost char[32], 
email varchar[100], 
address varchar[100], 
// 还需要其他数据吗?是否需要留出一定的保留值,以后alter table来 
// 增加新的字段时,效率如何? 

版面分类表:sclass 
classnum int unique, // 分类标识 
classid char[20], // 分类的英文id:computer 
classname varchar[100],// 分类的中文描述:电脑世界 
classtable char[20], // 特殊分类对应的版面表 
// 一般来说,每个版面只属于一个分类,对于特殊分类,例如拳头版块, 
// 新版面,可以用专门的表来描述 

版面表:sboard 
boardnum int unique, // 版面的标识(需要吗?) 
boardid char[20], // 版面的英文名 
boardname varchar[100], // 版面的中文名 
boardclass char[20], // 版面所属分类 
boardsysop varchar[100], // 斑竹名单 
boardposts int, // 版面的文章数 
boardlevel int, // 版面的读写权限 
indextable char[20], // 版面对应的索引表的名称:aboardid? 
texttable char[20], // 版面对应的文章表名称: bboardid? 
// 最后两项有没有必要出现,是否可以作为必然对应关系,还是允许 
// 出现更大的灵活性?另外版面的大小写问题是否可以直接默认 
// 只开头字母大写, 

特殊分类版面表:snewboard, sstarboard 
boardid char[20], // 版面的id 
// 这样的表有必要吗? 

版面索引表:acampus,alinux,afootball。。。。。。 
id int, // 文章序数,要手动调整???? 
mark char[1], // 文章标记,m,g,b,d。。。。 
title varchar[100], // 文章标题 
writer char[20], // 文章作者id 
posttime time, // 发表时间 
textnum longint, // 对应的编号???不调整 

版面文章表 
textnum longint, // 文章编号? 
textword text, // 文章内容? 
// 有必要将索引和文章内容分开吗?从效率上看,况且lazy flush 
// 是必然的。删除也是先做个标记。 

// 用户中的版面文章是否未读的数据比较繁,是否应该再建一堆的表 
// 才能实现呢? 
// 投票功能暂不考虑。。。。 

客户服务中心信箱:[email protected] [email protected] 网站地图

声明

合作伙伴: