现在有一个合同费用表 contract_ext,存放着各种合同相关的费率字段. 比如:
tax(利息), mgr(管理费),还有 n 多个费...
后来产品要求给有些费用添加类型字段,表示按月收 /按年收,于是在表中添加了 tax_type, mgr_type.
后来产品表示需要再加一些费用字段,于是这个表的字段蹭蹭蹭的加
后来产品说为了统一管理,要把一些字段删掉,于是这个表中出现了很多无用的字段
后来产品说...
我有预感,后来绝对只是个开始...
现在这种表结构设计给开发造成的痛点有:
- 表结构改动实在太频繁了,导致代码也要经常改
- 因为费用描述是放在字段的注释中,所以每次想查一个合同的费用明细,展示结果不是那么直观,需要结合字段注释来看.
目前改造的想法是将费用抽象出来,新建一个 contract_fee 表,里面有:
- id 主键
- contract_id 关联 contract id
- fee_name 费用名称(tax,mgr)
- fee_desc 费用描述(利息,管理费)
- fee_unit 费用单位(%/元)
- is_use 是否使用
- create_time 创建时间
这样如果产品后来再有什么需求,只需要 contract_fee 表添加数据就可以了,不需要改动表结构.但是会出现联表查询,可能会影响一些查询效率.
我昨天跟组长讨论了一下这个问题,组长说这个改动有点大(确实),让我再仔细考虑考虑.请教大家这种设计还会有哪些弊端呢.
像这种额外信息数据,经常变化但是有比较重要的字段(因为可能会涉及到最后还款计划的计算方式)需要如何设计才能保证良好的扩展性呢?
1
Select Language