字典表相关

workaround:

一个银行表: 主要字段: 银行名称,银行编号,业务类型BusinessLineId,服务提供商ID:serviceProviderID. 

关联逻辑:

根据业务线和银行code ,找到系统自定义银行id,

根据银行id和服务商id,找到银行名称和银行code,

于是如图所示:一个一行,至少在数据库中存储三张表

产生问题:

1 没有完整的文档交接,没有权限查看生产库,准生产库的数据和生产的不一致,且开发人员没有权限查看生产库,导致生产有脏数据,导致异常

2.开发代码管理问题,在准生产库 ,已经被UAT验证,但是生产执行的脚本,某些数据找不到,发现这条数据在最新的源代码脚本中无法找到,感觉代码被冲掉了

3.需求不停更改,导致对配置表的操作语句非常多,多大数百行(300多行,分在一个脚本的不同区域),追查起来非常乱(脚本是和task的顺序一样的),一两个月的工作,相关脚本就上百行,bank标的修改也是来来回回数次

4.这种逻辑关系在我第一次看代码时,认为非常不合理,现在(20170814)慢慢习惯了,,看后期有想发一定记录下来. 

自己初步想法:

1.字典表不会很多,也不会经常修改.字典表的脚本分类保存,能保持清晰的稳定性,bank表的初始化脚本,状态表的初始化脚本.

2.无法控制其他开发人员合并代码时,杜绝不获取服务器代码就合并从而导致代码冲掉的问题.

  程序员A 修改类A,先提交.程序员B 只修改类B,然后没有获取新代码,提交,这是程序员A的代码就会被程序员B的代码冲掉.

3.字典表的设计必须遵循越简单越好