工作中接到一个jave 开发人员说让我帮他写一个需求,因为我就是负责协助他们后台写数据库脚本的,这是我的责任。
可是没有想到这需求既然还有点复杂,没想太多,硬着头皮也要做出来。因为他自己不知道怎么整了,于是问了我,如果我还不会就只能找项目老大自己上了。
被坑得有点不要不要:第一次开发完成后我以为万事大吉了,最后既提交给测试那边说不是这个逻辑,测试给我的逻辑与开发给我的逻辑完全不一样啊,瞬间脑瓜则嗡嗡的响,都想找Java后台的同事好好聊聊人生了,发现还是算了,毕竟人家比我年长,我们这小屁孩也不敢说啊。其实心里还是挺不舒服的,但是谁让我们是一个团队的呢,直接把测试和后台开发的同事撸过来三人一起谈论,讨论发现有疑惑的又把老大叫了过来一起讨论,最终明确了具体的需求,再进行开发。
业务需求:
现在我们是有两种企业身份,假设A为发布活动企业,B为参与活动企业。
A企业下面有二级账号A_1,与三级账号A_1_1。B企业也是一样有二级账号B_1,三级账号B_1_1。
推荐代理商会可能是上面所有类型的身份中的一个。
现在需要实现的业务是,
如果推荐代理商为A则直接显示A,
如果推荐代理商为A企业下二级的A_1,则直接显示A_1。
如果推荐代理商为A企业下三级的A_1_1,则直接显示A_1。
如果推荐代理商为B则直接显示B。
如果推荐代理商为B企业下的B_1,则直接显示B。
如果推荐代理商为B企业下的B_1_1,则直接显示B。
-- 改造的
SELECT
-- 主要就是下面这个里的逻辑上的判断处理,已经后面需要两次关联同一个表来获取对应的三级供A_1_1的上一级账号A_1
if(es.enterprise_id is null,sd.rmd_supplier_name,(case when sd.enterprise_id=es.enterprise_id then ifnull(esp.supplier_name,sd.rmd_supplier_name) else es.enterprise_name end)) as rmdSupplierName,
if(es.enterprise_id is null,null,(case when sd.enterprise_id=es.enterprise_id then ifnull(esp.supplier_telephone,sd.rmd_supplier_mobile) else null end))as rmdSupplierMobile
FROM hrb_zp_settlement_info si
join hrb_zp_settlement_details sd on sd.cost_settlement_id=si.id and sd.in_use='1'
JOIN hrb_zp_info_request ir on ir.id = sd.ext1 and ir.in_use='1'
left join hrb_zp_settlement_pay pay on pay.id=sd.cost_pay_id and pay.in_use='1'
left join hrb_zp_enterprise_supplier es on es.supplier_id=sd.rmd_supplier_id and es.in_use='1'
left join hrb_zp_enterprise_supplier esp on esp.supplier_id=es.parent_supplier_id and esp.in_use='1'
where si.recruit_id = :recruit_id
-- 原来的
SELECT d.id,
d.enterprise_name enterpriseName,
d.supplier_name supplierName,
d.supplier_mobile as supplierMobile,
d.rmd_supplier_name rmdSupplierName,
d.rmd_supplier_mobile as rmdSupplierMobile
FROM hrb_zp_settlement_details d
JOIN hrb_zp_info_request r on r.id = d.ext1
left join hrb_zp_settlement_pay pay on pay.id=d.cost_pay_id
where cost_settlement_id = :cost_settlement_id
-- (比较坑的就是这个位置的入参:cost_settlement_id ,是后台开发同事自己事前已经写好的,然后让我在他这上面做修改,
--其实这个参数在系统中根本就没有传入进去,而是传了另外一个参数,然后去查找到这个入参,然后再做查询,刚开始后台开发的同事并没又与我说明,
--让我找了大半天都没有给重现系统页面应该出现的数据。重现数据对于我们数据库开发来说实在是太重要了,因为我们需要对数据有一个很清楚的认识我们
--才可以按照期望的样子将数据展现出来,就像这次开发的我的脑海中其实都是形成了一张上面六张表关联出来的所有字段的超大表,然后我再从这个超大的
-- 表上面不断的做过滤才能得到最终的结果)
and d.in_use = 1
and exists(
select 1 from hrb_zp_enterprise_info hzei where hzei.in_use='1' and hzei.enterprise_id=d.enterprise_id
union all
select 1 from hrb_zp_enterprise_supplier hzei where hzei.in_use='1' and hzei.supplier_id=d.supplier_id
)
<#if enterprise_name ?? && enterprise_name !=''>
and d.enterprise_name LIKE CONCAT('%','',CONCAT('',:enterprise_name ,'%'))
or d.supplier_name LIKE CONCAT('%','',CONCAT('',:enterprise_name ,'%'))
</#if>
总结:
一定要克制自己的冲动,凡事要顾全大局。
遇到不懂的,有疑问的,及时与大家进行全面的沟通。
不断地攻克难题才是最大得进步,处理简单的问题那就是原地踏步,我挺感谢我老大给我安排的这个职责的(负责帮后台开发人员处理复杂的业务逻辑数据),确实再最后弄好这个需求的时候其实内心还是很开心的,那种攻克难关的感受真是不言而喻。