写在断更之后,说好的每个月至少更新一篇博客也就这样淹没在每天无休无止的需求中。
我是一个技术人员,那么我就有义务去记录和分享我的问题,以及公布我的解决问题的思路,当然,肯定还有更好的解决方法的。
最近一段时间在做一个农村垃圾分类的需求,涉及到两条流程。一个是保洁员收垃圾的流程,还有一条是督导员根据保洁员收垃圾的结果来评分。
看似很简单,其中却又隐藏了……各种经常出现的bug。
首先,需求方提出的是要求每个村要自动获取,也就是我们目前有一个app端的信息上传通道,而该镇有19个村,这个容易解决,也就是登录的时候自动调用基础库里面的村的code,每一个code则对应了每一个村。后面就是某个村的某个保洁员收垃圾的过程,首先一个村有很多个保洁员,每一个保洁员是负责了好几户农户,他们想通过扫描二维码来实现信息录入,包括该农户的户主姓名、门牌号,在该基础信息上,就可以对该农户进行一个垃圾重量录入了,还可以进行上传照片。
这就是其中一个流程,另一个流程则是,当督导员过来的时候,也是通过app端扫描二维码来获取该户主的基本信息,通过户主姓名和门牌号到后台进行匹配今天是否有保洁员收取了该农户的垃圾,若有则显示该保洁员的姓名以及收取的垃圾量,根据保洁员的工作情况来进行打分。
以上就是两个流程的一个闭环操作,后面就是一个表结构设计以及后台代码实现和app端以及网页端的一个联动效果了。因为他们通过app端上传信息后,也要在网页展示页面相应的有一个汇总信息,包括保洁员收垃圾的情况以及督导员的评分情况。
表结构,我目前想的是在主页面展示的时候,一个保洁员对应一条收垃圾的信息,而督导员的打分则是按照农户为基础,有可能今天督导员为小明打了十分,则在网页上只展示总积分10分。如果第二天另一个督导员给小明打了十五分,则在网页上更新那一条总积分项为25分。但是我们又要能提供查看历史具体信息,例如哪一个督导员在什么时间打了几分,这就是一个查看历史积分的功能。我提供给每一个农户后面一个查看按钮,通过查看按钮即可获取以上信息。
在讨论表结构设计的时候,出现了分歧,我该以何种方式建立起主表和历史表之间的联系呢。一开始想到的是触发器。但是触发器还有一个问题,那就是如何将id值进行传递,以及主表需要的信息不需要传递到历史表中。后面我就想到出现第一个农户评分信息的时候是新增,后面检测到有该农户信息的时候就进行更新他的总积分,在历史表里则将主表中该农户的积分信息id值以及打分时间和打分的督导员新增进去。
这样,总积分的主表进行页面显示以及查看对应的某个人的历史打分情况就可以一一对应了。
但是我知道,一定还有更简单的实现方案。