|
3。數(shù)據(jù)庫設計
關鍵還是mysql的效率問題，合理分配mysql的內(nèi)存，特別是table cache的
大小。另外，當系統(tǒng)突然掉電呢？mysql是否robust？
table的名字設計，采用一位前綴表明類型，全部用小寫表示（？），例如：
系統(tǒng)的數(shù)據(jù)庫，以s為前導，如用戶表：suser（sUSER 呢？），具體如下：
s ：系統(tǒng)表，suser，sclass
m ：用戶信件表，msysop，mdrangon
w ：用戶消息表，wsysop，wdrangon
a ：版面索引表，alinux，acampus
b ：版面文章表，blinux，bcampus
c ：特殊分類版面表，cnewboard
i ：精華區(qū)索引表，ilinux，ilinux01，icampus，icampus04
j ：精華區(qū)文章表，jlinux，jcampus，
另外，是使用字串還是數(shù)字作為標識呢？例如，一個叫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種權(quán)限？
numlogins int,
numposts int,
firstlogin time,
lastlogin time,
staytime time, /* 總共停留時間 */
lasthost char[32],
email varchar[100],
address varchar[100],
// 還需要其他數(shù)據(jù)嗎？是否需要留出一定的保留值，以后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, // 版面的文章數(shù)
boardlevel int, // 版面的讀寫權(quán)限
indextable char[20], // 版面對應的索引表的名稱：aboardid？
texttable char[20], // 版面對應的文章表名稱： bboardid？
// 最后兩項有沒有必要出現(xiàn)，是否可以作為必然對應關系，還是允許
// 出現(xiàn)更大的靈活性？另外版面的大小寫問題是否可以直接默認
// 只開頭字母大寫，
特殊分類版面表：snewboard， sstarboard
boardid char[20], // 版面的id
// 這樣的表有必要嗎？
版面索引表：acampus，alinux，afootball。。。。。。
id int, // 文章序數(shù)，要手動調(diào)整？？？？
mark char[1], // 文章標記，m，g，b，d。。。。
title varchar[100], // 文章標題
writer char[20], // 文章作者id
posttime time, // 發(fā)表時間
textnum longint, // 對應的編號？？？不調(diào)整
版面文章表
textnum longint, // 文章編號？
textword text, // 文章內(nèi)容？
// 有必要將索引和文章內(nèi)容分開嗎？從效率上看，況且lazy flush
// 是必然的。刪除也是先做個標記。
// 用戶中的版面文章是否未讀的數(shù)據(jù)比較繁，是否應該再建一堆的表
// 才能實現(xiàn)呢？
// 投票功能暫不考慮。。。。
|
