由于眾所周知的原因，ACCESS在大型站點(diǎn)應(yīng)用中都靠不上邊，主要問題就是數(shù)據(jù)量大了以后幾乎無法索引。當(dāng)ACCESS里數(shù)據(jù)過萬后，明顯可以感覺到速度變慢，過2萬條數(shù)據(jù)后，慢的可以跟蝸牛相提并論了。但是由于某人靈光突現(xiàn)，想到了一個(gè)解決ACCESS數(shù)據(jù)庫承載問題的方案，那個(gè)某人就是偶啦……最喜歡搞歪門邪道地偶（另有小偷程序生成器）。

這個(gè)解決方案就是“ACCESS復(fù)合承載”（本人原創(chuàng)的詞，實(shí)在找不到合適的描述），簡單說就是將原來一個(gè)數(shù)據(jù)庫剝離為多個(gè)，成為一個(gè)主數(shù)據(jù)庫帶多個(gè)輔數(shù)據(jù)庫。拿我已經(jīng)實(shí)現(xiàn)的開良小說系統(tǒng)來說，小說信息都存儲(chǔ)在主數(shù)據(jù)庫內(nèi)，用于列表檢索，小說章節(jié)存在輔數(shù)據(jù)庫內(nèi)，每本小說獨(dú)立占一個(gè)數(shù)據(jù)庫。可能這樣你看著有點(diǎn)模糊，我們來下數(shù)據(jù)對(duì)比，一個(gè)小說站，算5個(gè)分類，每個(gè)分類400部小說，每部小說300章節(jié)（其實(shí)很多小說都不止300章節(jié)），那么數(shù)據(jù)量為5×400×300=60萬條數(shù)據(jù)，這還只是章節(jié)數(shù)據(jù)，其他的還有書目、用戶、評(píng)論等等數(shù)據(jù)，這樣大的數(shù)據(jù)量，即使是MYSQL或者M(jìn)SSQL也要好好規(guī)劃。但是，采用ACCESS復(fù)合承載以后，就會(huì)變成1個(gè)書目數(shù)據(jù)庫加2000個(gè)章節(jié)數(shù)據(jù)庫，每個(gè)章節(jié)數(shù)據(jù)庫里有300條數(shù)據(jù)，從只有300條記錄的ACCESS庫里讀東西，速度我想大家都能理解，即使是動(dòng)態(tài)讀取也絕對(duì)不慢。那么，這里又涉及到一個(gè)關(guān)鍵的問題，如何將主庫與輔庫連起來，這其實(shí)很簡單，我在小說系統(tǒng)里用的是用書目的ID來命名數(shù)據(jù)庫，將數(shù)據(jù)庫打開與關(guān)閉做成一個(gè)函數(shù)，要什么小說的章節(jié)就直接打開這個(gè)小說的數(shù)據(jù)庫就OK了。

談完方法，我們來談?wù)剝?yōu)缺點(diǎn)。優(yōu)點(diǎn)很顯著，其一，可以做以前很多做不了的事情，ACCESS庫原來根本做不了小說系統(tǒng)，現(xiàn)在可以做了，而且還可以做的很大。其二，ACCESS是以獨(dú)立文件形式存在的，可以很方便的實(shí)現(xiàn)復(fù)合承載，其他數(shù)據(jù)庫做不到這么方便。其三，一個(gè)數(shù)據(jù)庫僅幾百條數(shù)據(jù)，讀取效率絕不在其他數(shù)據(jù)庫之下（例如MYSQL 、MSSQL）。其四，ACCESS一般的空間都支持，通用性很高，而且大小不限哦。

接著來看缺點(diǎn)，第一，對(duì)程序員的要求也要高一些，數(shù)據(jù)庫的規(guī)劃必須要完善，數(shù)據(jù)庫多了后要用執(zhí)行SQL語句來修改格式，不懂編程語言的人是搞不了的。第二，數(shù)據(jù)檢索始終還是有缺陷（對(duì)于一些文章系統(tǒng)來說，小說系統(tǒng)壓根沒這缺陷），無法進(jìn)行全庫檢索，只能單庫檢索。

昨天晚上到今天早上一共花了8個(gè)小時(shí)，才把系統(tǒng)粗略做出來，睡眠不足，腦子都有點(diǎn)混，寫的亂七八糟（其實(shí)偶本來就不會(huì)寫，找個(gè)理由擋下。。），希望各位大大不要笑偶。。如果你也有邪門歪道的想法，也可以與我聯(lián)系哦。偶MAIL：klcode@qq.com，