MIS系统中最麻烦的查询不再于总共有多少个Join，而是在于确定需要多少个Join。用户什么条件都不选择时，最佳的做法就是直接对FACILITY表进行查询而不做任何Join；当用户选择了站点的条件时你除了必须加FACILITY表和SITE表的Join外，还必须先写上FACILITY表和PROJECT表的Join；用户同时选择了站点和设备编目时，除了FACILITY表 Join PROJECT表、FACILITY表 Join SITE表外，还得写上FACILITY表 Join FACILITY_CATALOG表。联结最多的情况就是用户同时选择了站点或CID以及设备编目的时候。而且这种确定需要多少个Join的问题也不是建一个视图能解决的。
开发MIS系统时，开发人员的主要精力应放在关注业务上，但在实际工作中，许多繁杂的事情都分散了开发人员的注意力。特别当一个团队的综合实力不强，新手或是初入门者居多时，问题更为显著。要么，为了图省事，全写上去，影响了系统的性能；要么就为了平凑出一个正确的SQL语句费尽心思。虽然如今有很多优秀的框架，实现了这样那样的功能，从一定程度上简化了开发人员的工作，但还是没能把开发人员真正的解放出来。现在正在讨论的用面向对象的思想处理查询，很多框架都已经实现了。可是本人观察了几个国内、国外的框架，以及一些书籍的例子代码后发现，这些实现都只是根据用户定义生成SQL语句，却无法做到优化生成的SQL语句。这里插一下我个人的观点：“如果只是原封不动生成SQL语句，还不如自己手写来得简便。”
经过一段时间的思考和总结后，我得出了如下结论：1、如果可以有一个自动化或半自动化的工具，只要输入所需的字段、条件、联结、分组、排序等，就可以替我们完成SQL语句的生成工作，必然能使开发人员有更多的时间去关注业务。2、如果1的方法可行，必然可以更进一步对这个工具进行优化，使其可以根据具体的数据库自动生成最优化的SQL语句。一方面可以提高新手的开发速度，另一方面还可以解决SQL语句造成的系统性能问题。3、如果可以有一个更加全面的框架或者平台，它不一定十全十美，但是可以完成一些重复、繁琐的工作，开发的效率同样可以得到提升。在使用的过程中，可以不断完善这个框架或者平台。可以这样设想，随着框架或者平台的不断完善，原先那些重复、繁琐的代码将不再出现，出错的几率也大大降低，这也意味着开发效率的进一步提高。当然，这些就是后话了。
回到主题。上面说了一大堆，可能让人更云里雾里。简单以之前那个数据结构为例简单说明一下：首先，根据查询的目标和具体的需求，将所有需要输出的字段和Join定义好（先不考虑其他的咚咚，如：GroupBy、Having、OrderBy等等）。接着，点击“搜索”按钮的时候将用户定义的条件加入到原先定义的查询中。最后，自动根据条件和输出的字段，选择所需的Join，最终组合成SQL语句输出。
由于不同的数据库所使用的数据类型不同，使用SQL语句查询时的语法也不同，所以针对Oracle数据库的代码直接搬到Access上就可能出错。最好的解决办法就是使用DbParameter，这样不仅可以解决不同类型数据库的问题，还可以在一定程度上解决SQL注入的问题。也可以算是一举多得吧。