基于mysql的bbs设计（二）
日期：2013-01-14 浏览次数：20479 次
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
// 是必然的。删除也是先做个标记。
// 用户中的版面文章是否未读的数据比较繁，是否应该再建一堆的表
// 才能实现呢？
// 投票功能暂不考虑。。。。
关键还是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
// 是必然的。删除也是先做个标记。
// 用户中的版面文章是否未读的数据比较繁，是否应该再建一堆的表
// 才能实现呢？
// 投票功能暂不考虑。。。。
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
