前幾天，老朋友叫我升級一下我以前做的一個ACCESS數(shù)據(jù)庫，是大概10年前做的，朋友還在使用，現(xiàn)在庫差不多一共有60多個GB大小了，我自豪感油然而生，不過當我打開數(shù)據(jù)庫，看里的一些代碼，很讓我臉紅。原來當初很多代碼都沒有效率，一些數(shù)據(jù)庫對象也做的比較松散。廢話不多說，讓我一一道來，讓剛開始學習ACCESS的朋友得到一些感悟。

    先說數(shù)據(jù)庫的結構吧，MDB+SQL的C/S模式，MDB采用鏈接表、ADO、DAO等綜合方式處理中間環(huán)節(jié)的數(shù)據(jù)，同時也是客戶端。SQL保存最終數(shù)據(jù)，同時保存了圖片，所以體積膨脹的比較厲害，這是預料中�，F(xiàn)在看來，減少了圖片在計算機中的管理環(huán)節(jié)，還是值得的。現(xiàn)在看來，我采用這種系統(tǒng)結構也是很合理的，50多人同時使用過程中沒有感覺卡頓，不過在做完業(yè)務，上傳數(shù)據(jù)的時候有一些卡，時常有數(shù)據(jù)上傳不成功的現(xiàn)象。

     分析：

     打開代碼一分析，原來上傳數(shù)據(jù)是將一張ACCESS的本地表所有數(shù)據(jù)合成一條記錄，并追加到SQL服務器表中，采用ADO的方式處理的數(shù)據(jù)，如果很多客戶端同時上傳，10~30秒才能處理完。ADO因為要打開表，如果表很大的話，僅打開表動作就能搞死機。 select 之后不要用*代替字段名稱，一定要僅把需要的字段羅列出來，同時加where把不要的記錄過濾掉。有關系表，要小表在左邊，大表放右邊。到底在ACCESS中執(zhí)行SQL代碼 ，還是在SQL服務器中去執(zhí)行SQL代碼，或是ADO去一句一句執(zhí)行，這個因地制宜，要分析的話，又得搞一個專題了。

     優(yōu)化總結：

     改用純SQL語句去處理了。很明顯感覺到快！上傳數(shù)據(jù)就是兩三秒的事情。根據(jù)我個人的實際體驗，能在服務器上處理，不影響整體性能，應該盡量在服務器上去處理數(shù)據(jù)，能用SQL盡量用SQL，但要少用游標之類的，萬不得已采用ADO或者DAO，感覺DAO比ADO更方便。個人感覺ACCESS使用鏈接表，在2010中比在2003中速度快。

    今天泛泛而談，以后有時間在談點詳細的吧。寫東西頭痛，今天到此結束。