业务系统数据库设计经验总结(十二)增减类业务表的解耦设计

【简化场景】
现有一批充电站,被一个物业公司运营着,用户来使用充电站里的设备给自己的电瓶车充电,每次充电会扫码付费。这里已经做好了这个公司的利润汇总表,每天的订单,根据充电桩的使用情况进行进账。当然这里面还涉及到这个公司和上级代理商的一些合同,分成等,为了简化场景这里不表述,但有个限制,这里公司每天的利润不能因为交了上级代理的管理费或者什么情况而变为负数。
现在来了新的需求,因为充电站所在的小区比较老旧,所以线路损耗是比较严重的,必须把这个情况考虑到利润的总额中,物业公司需要承担这部分的费用,设定每天的利润抽出最多50%来承担这个耗损,这个需求如何处理表结构的设计。
【设计一】
每天每个充电站进行线损的计算,存一个金额。而后在每天的利润里,抽出至多50%的金额,然后用之前的线损计算金额和这个对比,如果全部填补了,那么这笔账就平衡了。如果50%的利润都无法填补,那么这一天的线损金额可能就需要多次填补,我们需要补充一张额外的表,来记录第二次第三次填补信息,每次填补信息都生成一笔记录(这里假设补充填补的很少,90%的线损一次性就填补完成)。

这样做的好处是每一笔损耗,都能明白无误的找到一笔或者多笔利润进行对应。但是坏处就是无法提前预知这笔线损到底要多少笔利润来进行填补,这是个未知的因素。另外,在查找对应关系时是很麻烦的。
【设计二】
仔细分析,其实耗损这种变量,每天都有产生,每天都能填补,而两者并没有特别需要对应的关系。以上面的场景为例,并不是某笔电量损耗就必须用今天的利润去平衡,只要最终是平衡的就可以。这很像银行的流水,或者我们个人户头里的钱,我们不需要将发来的工资固定为某个特定的消费项目进行绑定(如果真的绑定,那应该是优惠券的场景)。可以将其设计为一个池子,记录池子的总量,而后将每一笔进的项目和出的项目记录清楚,就能够将两个业务解耦,如果后续还有其它的进项和出项,那么我们还能利用这套设计,而设计一就无能为力了。

【总结】
如设计二中的描述,其实这种用一个汇总的表来进行各种不同业务的进出量的处理,就能够将不同的业务解耦,这样在设计中灵活性和扩展性更好。由于场景和思维的限制,有些时候要想到这里并不是很自然,有些时候甚至需要我们主动去改变某个业务需求中的某个约束,才能将局面引导到这里,这也是经验的积累。如果设计中出现了类似第一次处理不完,需要后续再处理很多次的情况,那就需要想一想到底能否使用一个池子将两种或者多种业务剥离。

原文地址:https://www.cnblogs.com/bruceChan0018/p/15694893.html