关于 mysql 表设计问题,如果这样改,会有什么风险吗?

[lockerhyz]

现在有一个合同费用表 contract_ext,存放着各种合同相关的费率字段. 比如:

tax(利息), mgr(管理费),还有 n 多个费...

后来产品要求给有些费用添加类型字段,表示按月收 /按年收,于是在表中添加了 tax_type, mgr_type.

后来产品表示需要再加一些费用字段,于是这个表的字段蹭蹭蹭的加

后来产品说为了统一管理,要把一些字段删掉,于是这个表中出现了很多无用的字段

后来产品说...

我有预感,后来绝对只是个开始...

现在这种表结构设计给开发造成的痛点有:

1. 表结构改动实在太频繁了,导致代码也要经常改
2. 因为费用描述是放在字段的注释中,所以每次想查一个合同的费用明细,展示结果不是那么直观,需要结合字段注释来看.

目前改造的想法是将费用抽象出来,新建一个 contract_fee 表,里面有:

• id 主键
• contract_id 关联 contract id
• fee_name 费用名称(tax,mgr)
• fee_desc 费用描述(利息,管理费)
• fee_unit 费用单位(%/元)
• is_use 是否使用
• create_time 创建时间

这样如果产品后来再有什么需求,只需要 contract_fee 表添加数据就可以了,不需要改动表结构.但是会出现联表查询,可能会影响一些查询效率.

我昨天跟组长讨论了一下这个问题,组长说这个改动有点大(确实),让我再仔细考虑考虑.请教大家这种设计还会有哪些弊端呢.

像这种额外信息数据,经常变化但是有比较重要的字段(因为可能会涉及到最后还款计划的计算方式)需要如何设计才能保证良好的扩展性呢?

[testcount]

用后面的方案，另，感觉就没必要存什么费用名称费用描述了，这些写成常量放代码里就行。id, contract_id, fee_type, fee_amount, create_time 这几个字段就行了。contract_id 建索引，没啥大问题。

[lockerhyz]

@testcount 费用名称(tax,mgr)在计算还款计划表的时候会用到,比如还款计划表的利息=合同金额*月利息,如果不存在表里面的话,无法分辨这条数据是哪种费用.
费用描述,一般都是中文描述,主要是用来返回给前端的.

[lockerhyz]

@testcount 如果要保留 fee_name,那么这个字段要用什么类型呢,枚举吗?或者另外一种方案:再建一个费用配置表,将费用名称,费用描述放进费用配置表中?

[Miy4mori]

像这种字段经常变化的表一般有三种方式处理，一，横表转纵表，二，数据用 JSON 保存，三，凑合着做把。

[yy120345]

目前没啥大问题, 但是要考虑后续变更..... 嘤, 来到目前这家公司 后台我重构了 2 次 才刚刚整理好 , 数据库不知道改动多少次了, 好心累....大兄弟,设计表要慎重!!!

[lockerhyz]

@Miy4mori 我上面的方案,应该是属于横表转纵表吧?

[lockerhyz]

@yy120345 重构这种事,真的是让人又爱又怕.

[lockerhyz]

@yy120345 我的组长属于稳重型的,对于我提的改动建议,他也不确定值不值得采取

[Magic347]

一对多的关联查询之后还可以利用缓存层优化

[night98]

建议新增表，还可以单条查询

[lockerhyz]

@Magic347 缓存层优化属于后话了,大兄弟你觉得我这个分表方案怎么样,我主要是想知道合不合理,以及弊端是什么.

[lockerhyz]

@night98 新增表的话,按照我上面的方案拆分,会有什么问题吗?

[night98]

@lockerhyz 具体业务场景具体分析吧，另外多问一句这个 contract_fee 有没有同时关联多个 contract_ext，如果有的话把
contract_id 关联 contract id 这一行抽成一张映射表会好一些。