北京網(wǎng)站建設(shè)一般采用access數(shù)據(jù)庫(kù)就足夠了。
　　我想對(duì)于80％的網(wǎng)站來(lái)說(shuō)，它們的數(shù)據(jù)量采用access數(shù)據(jù)庫(kù)已經(jīng)足夠了。使用mysql或者sqlserver這些中型數(shù)據(jù)庫(kù)，往往需要增加額外的使用費(fèi)，而且數(shù)據(jù)量不大的時(shí)候，它們所反映的性能跟access數(shù)據(jù)庫(kù)并沒(méi)有多大的區(qū)別，故對(duì)于一般"玩家"來(lái)說(shuō)并不容易接受。最近sqlite數(shù)據(jù)庫(kù)異軍突起，采用其作為后臺(tái)數(shù)據(jù)庫(kù)的"玩家"也越來(lái)越多，我接觸它也有一年多的時(shí)間了，但都是在嵌入式平臺(tái)上面使用，因?yàn)閿?shù)據(jù)量小，一直沒(méi)有對(duì)其進(jìn)行過(guò)特別的性能測(cè)試。近期我也想"玩"一個(gè)網(wǎng)站，sqlite和access之間的選擇就擺在我面前了，事實(shí)勝于雄辯，就做了一個(gè)小程序來(lái)測(cè)試。
　　測(cè)試環(huán)境是奔4 3G + 512內(nèi)存 + vs2005 c#。由于網(wǎng)上有人說(shuō)加上下面的三句話(huà)：
　　　PRAGMA synchronous = OFF;
　　　PRAGMA page_size = 4096;
　　　PRAGMA cache_size = 70000;
可以讓sqlite的性能大幅度增加（不知道是否體現(xiàn)在超大數(shù)據(jù)量的時(shí)候），我也特地嘗試了一下。
采用事務(wù)提交的方法，每次插入5w條數(shù)據(jù)。不執(zhí)行上面三句話(huà)時(shí)執(zhí)行時(shí)間大都是2 s，少數(shù)是3s。執(zhí)行了上面三句話(huà)后大多數(shù)是3s ，少數(shù)是2 s。執(zhí)行查詢(xún)( id >10000 and id < 20000 ) 之間的數(shù)據(jù)，兩者執(zhí)行時(shí)間都是0.005s ，查詢(xún)count(*) 獲取所有數(shù)據(jù)條數(shù)時(shí)，加了三句話(huà)0.72~0.73s 比不加所耗的時(shí)間0.73s 快了一點(diǎn)點(diǎn)。25w條數(shù)據(jù)的文件大小為123兆。
　　access數(shù)據(jù)庫(kù)用的是2003格式，這里不由得要郁悶一下，access其實(shí)本身并不支持事務(wù)提交，它是通過(guò)OleDbTransaction來(lái)實(shí)現(xiàn)的，它在事務(wù)提交中給我的感覺(jué)跟一條一條插入毫無(wú)區(qū)別，唯一的區(qū)別就是出錯(cuò)了會(huì)回滾事務(wù)。所以它插入完25w條數(shù)據(jù)所消耗的時(shí)間是遠(yuǎn)遠(yuǎn)無(wú)法跟sqlite比較的。反正應(yīng)用中幾乎也用不到大數(shù)據(jù)量事務(wù)提交，只好忍了。但是需要導(dǎo)入數(shù)據(jù)的話(huà).....嘿嘿
　　相同的查詢(xún)語(yǔ)句，access用了0.047～0.06s，與sqlite相比，差距明顯。查詢(xún)count(*) 獲取所有數(shù)據(jù)條數(shù)時(shí)，用了0.06～0.07s，比sqlite稍有優(yōu)勢(shì)。25w條數(shù)據(jù)的文件大小為177兆。
　　綜合來(lái)說(shuō)，我覺(jué)得還是sqlite優(yōu)勢(shì)比較明顯。但是access數(shù)據(jù)庫(kù)維護(hù)要方便很多。