ACCESS複合承載 效能超越MYSQL

由於眾所周知的原因，ACCESS在大型網站應用中都靠不上邊，主要問題就是資料量大了以後幾乎無法索引。當ACCESS裡資料過萬後，明顯可以感覺到速度變慢，過2萬條資料後，慢的可以跟蝸牛相提並論了。但是由於某人靈光突現，想到了一個解決ACCESS資料庫承載問題的方案，那個某人就是偶啦……最喜歡搞歪門邪道地偶（另有小偷程式產生器）。

這個解決方案就是“ACCESS複合承載”（本人原創的詞，實在找不到合適的描述），簡單說就是將原來一個資料庫剝離為多個，成為一個主要資料庫帶多個輔資料庫。拿我已經實現的開良小說系統來說，小說資訊都儲存在主要資料庫內，用於列表檢索，小說章節存在輔資料庫內，每本小說獨立佔一個資料庫。可能這樣你看著有點模糊，我們來下資料對比，一個小說站，算5個分類，每個分類400部小說，每部小說300章節（其實很多小說都不止300章節），那麼資料量為5×400×300=60萬條資料，這還只是章節資料，其他的還有書目、使用者、評論等等資料，這樣大的資料量，即使是MYSQL或者MSSQL也要好好規劃。但是，採用ACCESS複合承載以後，就會變成1個書目資料庫加2000個章節資料庫，每個章節資料庫裡有300條資料，從只有300條記錄的ACCESS庫裡讀東西，速度我想大家都能理解，即使是動態讀取也絕對不慢。那麼，這裡又涉及到一個關鍵的問題，如何將主庫與輔庫連起來，這其實很簡單，我在小說系統裡用的是用書目的ID來命名資料庫，將資料庫開啟與關閉做成一個函數，要什麼小說的章節就直接開啟這個小說的資料庫就OK了。

談完方法，我們來談談優缺點。優點很顯著，其一，可以做以前很多做不了的事情，ACCESS庫原來根本做不了小說系統，現在可以做了，而且還可以做的很大。其二，ACCESS是以獨立檔案形式存在的，可以很方便的實現複合承載，其他資料庫做不到這麼方便。其三，一個資料庫僅幾百條資料，讀取效率絕不在其他資料庫之下（例如MYSQL 、MSSQL）。其四，ACCESS一般的空間都支援，通用性很高，而且大小不限哦。

接著來看缺點，第一，對程式員的要求也要高一些，資料庫的規劃必須要完善，資料庫多了後要用執行SQL語句來修改格式，不懂程式設計語言的人是搞不了的。第二，資料檢索始終還是有缺陷（對於一些文章系統來說，小說系統壓根沒這缺陷），無法進行全庫檢索，只能單庫檢索。

昨天晚上到今天早上一共花了8個小時，才把系統粗略做出來，睡眠不足，腦子都有點混，寫的亂七八糟（其實偶本來就不會寫，找個理由擋下。。），希望各位大大不要笑偶。。如果你也有邪門歪道的想法，也可以與我聯絡哦。