這里的文字主要是為了記錄下我的一些思路，以防日后遺忘。中途會經(jīng)歷相當(dāng)多的修改。有興趣的朋友歡迎指教。
關(guān)于我的網(wǎng)站應(yīng)該提供一些什么樣的功能、使用什么樣的用戶交互方式，雛形在我的腦中基本已經(jīng)形成了，但是還不系統(tǒng)。我需要趕快把它們記錄下來，免得以后忘了。當(dāng)然，在開發(fā)的過程中，我的思路隨時(shí)都會發(fā)生變化，因此這里記下的東西也會發(fā)生很多修改。一想到網(wǎng)站的功能，馬上就會想到要設(shè)計(jì)什么樣的數(shù)據(jù)庫來支持它。所以，這里的記錄主要是怎么設(shè)計(jì)數(shù)據(jù)庫。
數(shù)據(jù)庫軟件使用MySQL，先修改my.ini配置文件，默認(rèn)使用UTF-8編碼、InnoDB數(shù)據(jù)庫引擎，并啟動二進(jìn)制日志，以使得數(shù)據(jù)庫備份的工作變簡單些。
default-character-set = utf8
datadir = " D:/MySQL_Data/ "
innodb_data_home_dir = ./ibdata
innodb_log_group_home_dir = ./ibdata
innodb_data_file_path = ibdata1:50M:autoextend:max:1G
log-bin = ./bin_log/binlog
binlog-do-db = YumDaysIndex
binlog-do-db = YumDays001
然后開始創(chuàng)建數(shù)據(jù)庫，經(jīng)過前面在網(wǎng)站架構(gòu)方面的設(shè)想，我需要創(chuàng)建最少兩個(gè)數(shù)據(jù)庫：一個(gè)索引數(shù)據(jù)庫，一個(gè)或多個(gè)內(nèi)容數(shù)據(jù)庫。我把索引數(shù)據(jù)庫命名為YumDaysIndex，內(nèi)容數(shù)據(jù)庫命名為YumDaysNNN，其中的NNN是數(shù)字編號，在剛開始的時(shí)候，肯定只要一個(gè)YumDays001就夠了。
GRANT ALL PRIVILEGES ON YumDaysIndex.* TO '********'@'%' IDENTIFIED BY '********' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON YumDays001.* TO '********'@'%' IDENTIFIED BY '********' WITH GRANT OPTION;
CREATE DATABASE YumDaysIndex;
CREATE DATABASE YumDays001; 選擇YumDays001數(shù)據(jù)庫，創(chuàng)建用戶表：
USE YumDays001;
CREATE TABLE users(
id char(32) NOT NULL PRIMARY KEY,
name varchar(30) NOT NULL,
password char(32) NOT NULL,
monicker varchar(30) NOT NULL,
question varchar(30) NOT NULL,
answer varchar(30) NOT NULL,
email varchar(30) NOT NULL,
qq varchar(12) NOT NULL,
roleid char(32) NOT NULL,
score int NOT NULL DEFAULT 0,
albumusage int NOT NULL DEFAULT 0,
regtime timestamp NOT NULL DEFAULT '2008-01-01 00:00:00',
logintime timestamp NOT NULL DEFAULT '2008-01-01 00:00:00',
isdeleted varchar(2) NOT NULL DEFAULT '0',
INDEX(name),
INDEX(monicker)
);
這樣一些字段分別代表ID、用戶名、密碼、昵稱、密碼問題、答案、email、QQ號、用戶角色、積分、相冊已經(jīng)使用的磁盤空間、注冊時(shí)間、登錄時(shí)間、是否刪除等。設(shè)計(jì)這個(gè)表的思路如下：
1、name只能用英文，因?yàn)樗鼘⑹荱RL的組成部分，為了便于用戶之間的識別，所以需要monicker（昵稱）字段；
2、根據(jù)用戶的score字段可以算出用戶的相冊容量，每次上傳圖片的時(shí)候，都增加albumusage字段的值，如果空間已經(jīng)被使用完，則不容許上傳；
3、ID使用UUID類型，所以它的列類型為char(32)，之所以使用UUID，是因?yàn)閡sers表會被分割到很多個(gè)數(shù)據(jù)庫中，使用UUID可以保證ID的唯一性；
4、isdelete的列類型也比較奇怪，為varchar(2)，而默認(rèn)值卻是'0'（字符串），這是因?yàn)镾pringSide的實(shí)現(xiàn)中，在刪除數(shù)據(jù)的時(shí)候，會把這個(gè)字段設(shè)置為'-1'（字符串）。
從這個(gè)表中可以看出，這里涉及到一個(gè)用戶角色的問題，不同的角色擁有不同的權(quán)限，所以需要一個(gè)Roles表。考慮到Roles表包含的記錄數(shù)不會太多，而且分布到多個(gè)服務(wù)器上也不好維護(hù)，所以Roles表應(yīng)該放到索引服務(wù)器中。用戶登錄這樣的過程也應(yīng)該由索引服務(wù)器處理，然后將用戶的一些信息保存到Cookie中，不過如果用戶操作的時(shí)候需要查看權(quán)限，則一定要向索引服務(wù)器請求，索引服務(wù)器通過提供WebService來響應(yīng)請求，因?yàn)樵贑ookie中保存權(quán)限會出現(xiàn)安全問題。
創(chuàng)建Roles表的代碼如下：
USE YumDaysIndex;
CREATE TABLE roles(
id char(32) NOT NULL PRIMARY KEY,
name varchar(20) NOT NULL,
privilegesflag varchar(255),
INDEX(name)
);
這里需要說明的是privilegesflag字段，該字段我設(shè)計(jì)為一個(gè)用逗號隔開的字符串，比如“post,reply”，代表用戶具有發(fā)帖、回帖的權(quán)限。這么設(shè)計(jì)的好處就是在開發(fā)過程中，不用為了增加權(quán)限而修改數(shù)據(jù)表的結(jié)構(gòu)，只用往這個(gè)表中加入新的字符串就行了，而Java代碼中，分割字符串又是那么的方便。
在這個(gè)表中，我初步設(shè)計(jì)的角色有四個(gè)，它們分別是管理員、超級用戶、普通用戶和被鎖定用戶。當(dāng)然，如果網(wǎng)站規(guī)模越來越大，需要有人幫著把關(guān)時(shí)（否則肯定黃帖廣告貼泛濫），可能需要版主、編輯這樣的角色。
在我剛開始設(shè)計(jì)這個(gè)系統(tǒng)時(shí)，本來是加入了用戶群組的功能的，但是經(jīng)過這兩天的沉淀，我決定暫時(shí)還是不要這個(gè)功能了。以后再加上都可以，但是開發(fā)初期我不想為自己找太多麻煩。
文章要進(jìn)行分類，因此需要創(chuàng)建一個(gè)分類表，這個(gè)表依然保留在索引服務(wù)器上：
CREATE TABLE catalogs(
id char(32) NOT NULL PRIMARY KEY,
name varchar(20) NOT NULL,
INDEX(name)
);
這個(gè)表的內(nèi)容很簡單，無需解釋。
再下面，就是用來保存文章的表了：
USE YumDays001
CREATE TABLE topics(
id char(32) NOT NULL PRIMARY KEY,
catalogid char(32) NOT NULL,
subject varchar(60) DEFAULT NULL,
content text,
summary varchar(300) default NULL,
mainpicture varchar(100) NOT NULL,
userid char(32) NOT NULL,
time timestamp NOT NULL default CURRENT_TIMESTAMP,
lastedittime timestamp NOT NULL default '2007-01-01 00:00:00',
lastreplytime timestamp NOT NULL default '2007-01-01 00:00:00',
visitcount int NOT NULL,
accessmod tinyint NOT NULL,
INDEX(subject),
INDEX(userid),
INDEX(time),
INDEX(lastreplytime)
);
該表應(yīng)該保存到內(nèi)容數(shù)據(jù)庫中。其中的字段都很好理解，從名字即可看出意義。其中需要解釋的兩個(gè)字段如下：
1、mainpicture：我希望每一篇文章都有一個(gè)主題圖片，該圖片在顯示文章列表的時(shí)候也可以顯示（當(dāng)然是縮略圖）。其內(nèi)容是一個(gè)URL。
2、accessmod：該字段保存了該文章的安全屬性，即是否公開。取值為1則不公開，取值為3則完全公開。那么2呢？那是我為用戶群保留的，取值為2則只正對該文章所屬的群公開。
至于索引，那是要根據(jù)網(wǎng)站需要提供什么樣的功能來設(shè)計(jì)的。當(dāng)網(wǎng)站需要按照哪一個(gè)規(guī)則對文章進(jìn)行查找的時(shí)候，就要在該字段上建立索引，以便加快查找速度。
再往下，則是用來保存回復(fù)的表：
CREATE TABLE replys(
id char(32) NOT NULL PRIMARY KEY,
subject varchar(50) NOT NULL,
content text,
userid char(32) NOT NULL,
time timestamp NOT NULL default CURRENT_TIMESTAMP
);
自己回復(fù)了哪些文章，心里也要有個(gè)數(shù)，所以要建立一個(gè)表，用來記錄用戶參與了的文章：
CREATE TABLE participation(
id char(32) NOT NULL PRIMARY KEY,
userid char(32) NOT NULL,
topicid char(32) NOT NULL,
INDEX(userid)
);
再然后，是用來管理相冊和相片的表：
create table albums(
id char(32) NOT NULL PRIMARY KEY,
userid char(32) NOT NULL,
name varchar(20) NOT NULL,
description varchar(200) DEFAULT NULL,
photopath varchar(30) NOT NULL,
miniphotopath varchar(30) NOT NULL,
accessmod tinyint NOT NULL,
INDEX(userid)
);
這里的photopath是該相冊在服務(wù)器上的文件路徑，而miniphotopath則是縮略圖的路徑。accessmod也是起安全控制作用的，意義同前。
CREATE TABLE photos(
id char(32) NOT NULL PRIMARY KEY,
albumid char(32) NOT NULL,
filename varchar(20) NOT NULL,
INDEX(albumid)
);
這樣，內(nèi)容數(shù)據(jù)庫的表已經(jīng)差不多了，剩下的在開發(fā)過程中再逐步完善。而索引服務(wù)器還只有前面提到的Roles表和Catalogs表，但是索引服務(wù)器要提供顯示首頁的功能，要提供反向代理的功能，要提供統(tǒng)計(jì)排序的功能。因此，我在索引數(shù)據(jù)庫中設(shè)計(jì)了以下表。
首先，索引服務(wù)器中也應(yīng)該保存有Users的所有數(shù)據(jù)，需要保存所有的記錄，但是不需要保存所有的字段。初步的設(shè)計(jì)如下：
USE YumDaysIndex;
CREATE TABLE users(
id char(32) NOT NULL PRIMARY KEY,
name varchar(30) NOT NULL,
password char(32) NOT NULL,
monicker varchar(30) NOT NULL,
roleid char(32) NOT NULL,
score int NOT NULL DEFAULT 0,
webserver varchar(10) NOT NULL,
INDEX(name),
INDEX(score)
);
這里保存有用戶的驗(yàn)證信息，因此簡單的驗(yàn)證功能都可以通過索引服務(wù)器來完成。這里有兩個(gè)字段值得一提，一是score，用來保存用戶的分?jǐn)?shù)，主要是為了實(shí)現(xiàn)用戶排名；另一個(gè)字段是webserver，它保存了該用戶會被分配到那個(gè)Web服務(wù)器。
索引服務(wù)器還應(yīng)該保存所有Topics的記錄，當(dāng)然，它不需要保存所有的字段，和Users表一樣，它只需要知道到哪個(gè)Web服務(wù)器可以找到這個(gè)Topic的所有數(shù)據(jù)就行了。初步設(shè)計(jì)如下：
CREATE TABLE topics(
id char(32) NOT NULL PRIMARY KEY,
catalogid char(32) NOT NULL,
time timestamp NOT NULL default CURRENT_TIMESTAMP,
webserver varchar(10) NOT NULL,
INDEX(time)
);
這個(gè)表非常簡單，只是維護(hù)了一個(gè)所有Topic的索引而已，通過webserver字段就知道到哪里找它的詳細(xì)信息，索引服務(wù)器顯示主頁的時(shí)候，可以通過AJAX調(diào)用相應(yīng)的webserver來顯示它的摘要信息。time字段是用來排序的，catalog字段是用來分類的。
我還有一個(gè)想法，就是想能夠按照最新的回復(fù)來對Topic進(jìn)行排序，基本上所有的論壇都是采取的這種方法，只需要有人回復(fù)，文章就會被頂上去。但是，由于Topics是分布存儲的，所以需要有一個(gè)表用來保存最近被回復(fù)的文章的信息，而其它的服務(wù)器則可以通過定時(shí)服務(wù)，每隔幾分鐘在自己的服務(wù)器上統(tǒng)計(jì)最新被回復(fù)的文章，然后提交到索引服務(wù)器。其結(jié)構(gòu)如下：
CREATE TABLE hottopics(
id char(32) NOT NULL PRIMARY KEY,
subject varchar(60) NOT NULL,
lastreplytime timestamp NOT NULL default '2007-01-01 00:00:00',
sebserver varchar(10) NOT NULL,
INDEX(lastreplytime)
);
這個(gè)表，只需要保存少量的紀(jì)錄就夠了。
還要一個(gè)統(tǒng)計(jì)表，維護(hù)一些統(tǒng)計(jì)信息，如注冊用戶數(shù)、文章總數(shù)、回復(fù)總數(shù)、響應(yīng)新用戶注冊的當(dāng)前服務(wù)器等等，如下：
CREATE TABLE statistic(
usercount int NOT NULL,
topiccount int NOT NULL,
replycount int NOT NULL,
currentwebserver varchar(10) NOT NULL
);
這個(gè)表的名字是單數(shù)形式，因?yàn)檫@個(gè)表只需要一條紀(jì)錄就夠了。
索引服務(wù)器還需要維護(hù)所有的相冊信息，同Topics表一樣，其結(jié)構(gòu)如下：
CREATE TABLE albums(
id char(32) NOT NULL PRIMARY KEY,
time timestamp NOT NULL default CURRENT_TIMESTAMP,
webserver varchar(10) NOT NULL,
INDEX(time)
);
數(shù)據(jù)庫的設(shè)計(jì)到此告一段落，下一步就開始寫代碼了。數(shù)據(jù)庫設(shè)計(jì)中的缺陷，只有經(jīng)過實(shí)戰(zhàn)的檢驗(yàn)才能夠體現(xiàn)出來。