1、喜欢嵌套查询，以求一步到位。在这里比较少见，不过我经常逛EH（club.excelhome.net），里面估计不少人受SQL Server毒害不浅，于是，好端端的几个查询，就给Select * from (select * form (select * from A) As B) As C这么“As”下去了。我想说的是，多做两个查询会死啊？在SQL Server里嵌套是常有的事情，毕竟从运行效率来看，影响不大。但对Access来说就不一样了，这样往往会降低查询效率。当然可能不少人觉得多做几个查询看得麻烦，容易混淆，不知道哪个是干嘛的。没关系，我们可以按顺序和一定的格式进行命名。如果觉得这还不够，我们还可以在属性里写上说明。这不就一清二楚了？

       2、喜欢把查询转换成VBA代码。记得学习之初，我也有把查询改成SQL语句的习惯，——大概持续了一周吧，后来才发现其中的坏处。

       坏处一：无法发现表关系。在VBE界面里，除非对SQL已经烂熟，否则很难一下子辨别出表关系来，反正我没有这本事。

       坏处二：调试麻烦，出错时要多次在立即窗口打印出SQL语句，说不定还要把这些语句放在QBE界面进行测试才能找到问题的所在。

       坏处三：维护麻烦。例如用户提出要求增加某个字段，减少哪几个字段时，或者增加某些功能时。如果不能说服客户的话，这时候估计有人得累一段时间了。

       3、不喜欢交互，奢望一步到位。最明显的就是希望在Access里处理一些Excel函数。这些我早在一些帖子上提到过了，不是不可以，但代码的调试不见得比在Excel里处理的时间短。对于比较复杂的函数，我一般都是在Excel里处理完毕再导入到Access里的。其实这都是工具，我们不必因为Access在数据管理上的优势，就抛弃Excel应有的数据处理功能。

       4、“Excel后遗症”的数据表设计。说是Excel后遗症，一点都不过分。包括我们公司初期开发的一些数据库系统，都存在这样的问题。Excel的表格比较直观，所以通常有这样的显示：

       姓名        语文     数学     英语     化学     物理      生物      地理      历史      体育      美术     音乐

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

       但这种格式的设计在Access里要不得，因为不利于数据的优化，而且也不方便查询。像这个例子，在Access里只需要三个字段：姓名（文本型）、科目（文本型）、成绩（数值型）。受Excel影响比较深的朋友可能会问了，如果我想显示成上面那样，该怎么办？很简单，交叉表查询，把成绩作为列标题，姓名作为行标题，成绩作为值，效果就出来了。

       5、迷恋代码。在上一篇已经提到了，这里不打算多说。实际上不是什么都得依靠代码的。对我来说，只有其它功能无法实现的时候，才考虑代码，因为代码调试起来并不是一件很愉快的事情。

       在Access的学习里，其实很多东西都要进行思考的。在设计一个软件之前，应先考虑大致框架的建设，再根据这些框架设计表字段，然后通过查询来完成这些功能，最后再迁移到窗体上去进行显示。当然，说起来很简单，实际做起来并不见得。