标签：
我们常常要实现检索数据的功能。复杂的查询条件输入，最好有辅助输入功能，能帮助使用者更轻松的完成查询条件输入。最近我们见到一个查询条件输入功能实现的时候犯的一个低级错误，觉得在新手中可能会典型，故拿出来说一下。
有个查询基站监控历史数据的功能，要查基站的历史数据，先得选择几个基站。第一个版本查询条件很简单，只需按站名或地区搜索基站，在结果集中选中一个或多个站，再输入其他查询条件。第二个版本，客户要求增加基站的基础信息作为查询条件，比如郊区还是市区，墙体材料等等，这些条件影响基站的冷却所需的能耗。这个系统在部署在不同的客户的时候，要求有所不同，有的客户不关心能耗完全没必要安置此查询条件；有的关心，此条件必须。为了统一版本，减少维护代价，这样一来，这个与能耗有关的查询条件在系统中是可选的。
一般来说，被查询的数据集是相对稳定的，较少会变化；而查询条件是多变的。
这个实现在原有的基站表之外另建一个基站附加属性表，与基站表一一对应，如果有某站的基础信息，附加表中就有记录，没有就无记录。每一个附加属性都在附加表中加一列。这样的设计不算完美，增加附加属性将需要改表，改所有与表有关的代码，不是很有灵活性。
接下来，亮点出现了。在实现助选基站的筛选功能的时候，查的表竟然不是基站表这个主表，而是查这个存放可选信息的附加表！这样出现的结果是，在没有监测能耗的客户那里，由于附加表中无数据，所以选不到基站！
开发此功能的筒靴认为，“你只要在附加表中配置附加信息就可以选基站了”！但是，你让没有这些内容的顾客如何填写这些内容！
总结一下这个问题：
1.查基站一定要从基站表中查，其他地儿都是浮云；
2.作为过滤条件的属性，无论是存在于主表中还是附加表还是其他表，都是作用在主表中的数据集上的过滤谓词的组成部分；
3.而查询条件的多变性，决定了这些属性是可选的。
4.什么是数据集，什么是过滤条件，应从原始问题出发来判断，而不能因为过滤条件中也有所要的字段就颠倒主次。
这个问题看起来有点 low，但是此类问题并不罕见，所以将其记下，引以为戒。
关于实现数据查询条件输入功能的一个低级错误
标签：
原文地址：http://www.cnblogs.com/a-events/p/4662947.html
