单号业务优化方案总结

赢海

背景

基于天津永续客户提出对于单号的要求,针对单号进行优化和可设置操作,现产品提出对于单号的优化方案进行总结

设计方面

设计图

字段方面可能考虑不全

现有单号生产拼接字段有: 船舶简称、部门、年份、申请类型、申请序号这个几个字段

讨论后发现基于行业和后续客户考虑是否会有其他字段需求,如: 公司简称、角色、职务、随机数、日期、平台类型等

产品解决方案

基于暂时客户以及业务需求, 目前设计的字段就可满足,其他类型如果有后续需求在进行添加

字段校验问题

1. 部门(甲板部标识、轮机部标识、岸基标识),是不能为空并且不能重复的
2. 如果年份字段不做选择,那面申请序号-顺番 固定为5位, 防止单号顺番溢出

船舶简称问题

1. 船舶简称会出现中文以及其他特殊字符或者存在过长的问题

技术方面

架构服务

目前处理方案只是过渡方案以及快速解决客户问题

经架构组讨论这里应该单独有一个单独的单号生产系统,进行单号统一配置,生成以及管理

单号唯一性

目前技术方案在单号唯一性方面可能会存在风险

因为目前的设计是在生成单号时候查询顺番号进行递增, 如果几个人同时操作有存在单号重复的风险,所以在创建订单时候还要针对单号唯一性进行校验

单号业务侵入问题

目前技术方案是在业务表中插入一个生成单号的规则作为后续单号的重建以及拆分或者合并

这样在架构级别考虑耦合性过高, 后期重构风险成本也比较大

删除使用问题

如果单号删除后在进行单号查询使用后, 不会使用之前生成过并且删除的单号

单号重复设置问题

目前单号产品设计只允许设置一次, 如果在使用过程中设置错误或者客户有修改需要此情况为进行考虑

重构风险

目前基于设计方案以及时间要求,在推进次需求优化时候只能进行业务表侵入这种方式进行推进开发,后续进行重构够优化成本比较大

重构数据表设计

架构组基于单号业务进行系统级别考虑,出的一个数据库ER图,根据这个方案设计预计开发时间需要后台(三周), 前端(两周)的时间,并且在基于现有修改在重构,后台还需要多一周的重构现有逻辑的时间

总结

产品基于客户需求以及开发时间限制,目前开发使用现有设计进行业务表侵入方案进行单号开发 , 可以解决客户需要的问题. 此方案不足之处就是对于架构业务上耦合性太强, 后续如果客户有其他需求不满足的,需要进行重构开发.