物业收费一般根据国家《物业管理条例》分为两种类型,
第一种:用户消耗的水电用量
在一个收费期段内,根据水表,电表计量的消耗量乘以单价,就是水电费。这种归类原因,主要是有计量消耗量数据的仪表。
第二种:用户期段内的服务费
例如:物业管理费,电梯费,卫生费等。这些费用计算的标准大多通过一个时间期段(如:每月、每天、每季度、每年等)还有用户住房的面积,住户人数等相关参数,来合理确定收费标准。
比如:卫生费由于住户的常住人口多,产生的生活垃圾等就多所以在收取卫生费的时候就要求将住户人数作为一个参数,这样收费对大多数用户来说更合理公平。
下面来谈下业务逻辑的数据库设计和实现。
基本信息表
查询视图
这里的设计内容比较多,大家都能设计出更好的。
我主要介绍下“视图_物业应交”这个视图的设计。
先提出点问题,算是引子
按照时间间隔收费,这个时间的间隔一般分为:“每月一次|每年一次|每天一次|每季度一次 ”四种,在实现SQL查询集合中就需要判断处理来解决,一种就是上一篇文章提到的IIF()函数。http://hi.baidu.com/chinameter/blog/item/00732b81f9b330c9bd3e1ef3.html
在由于收取的物业项目很有可能和住户的面积及常住人口数量有关系,所以设计这种嵌套的判断逻辑关系可读性,就变的异常复杂。
通过思考我打算采用交集(UNION)来实现,这样每一种可能定义的收费方式单独形式交集的一个子集,在把这些子集集合到一起也可以解决复杂嵌套判断逻辑结构复杂,不容易维护、升级等问题。
还有一个要点也等提一下。
在处理按照每年一次收费的时候,由于时间较长,一般都在自然年(就是新的一年开始后)来收取的,例如:暖气费大多在供暖前期,例如:11月15日供暖前就已经收取了。若要按照自然年在计算费用,肯定是有滞后性,不符合时间业务管理需求。要动态定义提前月份 和日期来实现这样的功能,才能和实际相结合有效的处理这样的特殊情况的业