1、喜歡嵌套查詢，以求一步到位。在這里比較少見，不過我經(jīng)常逛EH（club.excelhome.net），里面估計不少人受SQL Server毒害不淺，于是，好端端的幾個查詢，就給Select * from (select * form (select * from A) As B) As C這么“As”下去了。我想說的是，多做兩個查詢會死��？在SQL Server里嵌套是常有的事情，畢竟從運行效率來看，影響不大。但對Access來說就不一樣了，這樣往往會降低查詢效率。當然可能不少人覺得多做幾個查詢看得麻煩，容易混淆，不知道哪個是干嘛的。沒關(guān)系，我們可以按順序和一定的格式進行命名。如果覺得這還不夠，我們還可以在屬性里寫上說明。這不就一清二楚了？

       2、喜歡把查詢轉(zhuǎn)換成VBA代碼。記得學習之初，我也有把查詢改成SQL語句的習慣，——大概持續(xù)了一周吧，后來才發(fā)現(xiàn)其中的壞處。

       壞處一：無法發(fā)現(xiàn)表關(guān)系。在VBE界面里，除非對SQL已經(jīng)爛熟，否則很難一下子辨別出表關(guān)系來，反正我沒有這本事。

       壞處二：調(diào)試麻煩，出錯時要多次在立即窗口打印出SQL語句，說不定還要把這些語句放在QBE界面進行測試才能找到問題的所在。

       壞處三：維護麻煩。例如用戶提出要求增加某個字段，減少哪幾個字段時，或者增加某些功能時。如果不能說服客戶的話，這時候估計有人得累一段時間了。

       3、不喜歡交互，奢望一步到位。最明顯的就是希望在Access里處理一些Excel函數(shù)。這些我早在一些帖子上提到過了，不是不可以，但代碼的調(diào)試不見得比在Excel里處理的時間短。對于比較復雜的函數(shù)，我一般都是在Excel里處理完畢再導入到Access里的。其實這都是工具，我們不必因為Access在數(shù)據(jù)管理上的優(yōu)勢，就拋棄Excel應有的數(shù)據(jù)處理功能。

       4、“Excel后遺癥”的數(shù)據(jù)表設計。說是Excel后遺癥，一點都不過分。包括我們公司初期開發(fā)的一些數(shù)據(jù)庫系統(tǒng)，都存在這樣的問題。Excel的表格比較直觀，所以通常有這樣的顯示：

       姓名        語文     數(shù)學     英語     化學     物理      生物      地理      歷史      體育      美術(shù)     音樂

       Roych     98        95        89        92        88         79          72         81         77        85        72

       但這種格式的設計在Access里要不得，因為不利于數(shù)據(jù)的優(yōu)化，而且也不方便查詢。像這個例子，在Access里只需要三個字段：姓名（文本型）、科目（文本型）、成績（數(shù)值型）。受Excel影響比較深的朋友可能會問了，如果我想顯示成上面那樣，該怎么辦？很簡單，交叉表查詢，把成績作為列標題，姓名作為行標題，成績作為值，效果就出來了。

       5、迷戀代碼。在上一篇已經(jīng)提到了，這里不打算多說。實際上不是什么都得依靠代碼的。對我來說，只有其它功能無法實現(xiàn)的時候，才考慮代碼，因為代碼調(diào)試起來并不是一件很愉快的事情。

       在Access的學習里，其實很多東西都要進行思考的。在設計一個軟件之前，應先考慮大致框架的建設，再根據(jù)這些框架設計表字段，然后通過查詢來完成這些功能，最后再遷移到窗體上去進行顯示。當然，說起來很簡單，實際做起來并不見得。