V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
lockerhyz
V2EX  ›  程序员

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

  •  
  •   lockerhyz · 2018-03-15 10:43:41 +08:00 · 3307 次点击
    这是一个创建于 2471 天前的主题,其中的信息可能已经有所发展或是发生改变。

    现在有一个合同费用表 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 表添加数据就可以了,不需要改动表结构.但是会出现联表查询,可能会影响一些查询效率.

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

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

    13 条回复    2018-03-15 19:53:48 +08:00
    testcount
        1
    testcount  
       2018-03-15 10:57:29 +08:00   ❤️ 1
    用后面的方案,另,感觉就没必要存什么费用名称费用描述了,这些写成常量放代码里就行。id, contract_id, fee_type, fee_amount, create_time 这几个字段就行了。contract_id 建索引,没啥大问题。
    lockerhyz
        2
    lockerhyz  
    OP
       2018-03-15 11:08:30 +08:00
    @testcount 费用名称(tax,mgr)在计算还款计划表的时候会用到,比如还款计划表的利息=合同金额*月利息,如果不存在表里面的话,无法分辨这条数据是哪种费用.
    费用描述,一般都是中文描述,主要是用来返回给前端的.
    lockerhyz
        3
    lockerhyz  
    OP
       2018-03-15 11:11:16 +08:00
    @testcount 如果要保留 fee_name,那么这个字段要用什么类型呢,枚举吗?或者另外一种方案:再建一个费用配置表,将费用名称,费用描述放进费用配置表中?
    Miy4mori
        4
    Miy4mori  
       2018-03-15 12:20:03 +08:00
    像这种字段经常变化的表一般有三种方式处理,一,横表转纵表,二,数据用 JSON 保存,三,凑合着做把。
    yy120345
        5
    yy120345  
       2018-03-15 12:53:30 +08:00
    目前没啥大问题, 但是要考虑后续变更..... 嘤, 来到目前这家公司 后台我重构了 2 次 才刚刚整理好 , 数据库不知道改动多少次了, 好心累....大兄弟,设计表要慎重!!!
    lockerhyz
        6
    lockerhyz  
    OP
       2018-03-15 14:08:27 +08:00
    @Miy4mori 我上面的方案,应该是属于横表转纵表吧?
    lockerhyz
        7
    lockerhyz  
    OP
       2018-03-15 14:10:15 +08:00
    @yy120345 重构这种事,真的是让人又爱又怕.
    lockerhyz
        8
    lockerhyz  
    OP
       2018-03-15 14:12:28 +08:00
    @yy120345 我的组长属于稳重型的,对于我提的改动建议,他也不确定值不值得采取
    Magic347
        9
    Magic347  
       2018-03-15 16:38:18 +08:00
    一对多的关联查询之后还可以利用缓存层优化
    night98
        10
    night98  
       2018-03-15 17:55:29 +08:00 via Android
    建议新增表,还可以单条查询
    lockerhyz
        11
    lockerhyz  
    OP
       2018-03-15 19:01:05 +08:00
    @Magic347 缓存层优化属于后话了,大兄弟你觉得我这个分表方案怎么样,我主要是想知道合不合理,以及弊端是什么.
    lockerhyz
        12
    lockerhyz  
    OP
       2018-03-15 19:02:19 +08:00
    @night98 新增表的话,按照我上面的方案拆分,会有什么问题吗?
    night98
        13
    night98  
       2018-03-15 19:53:48 +08:00
    @lockerhyz 具体业务场景具体分析吧,另外多问一句这个 contract_fee 有没有同时关联多个 contract_ext,如果有的话把
    contract_id 关联 contract id 这一行抽成一张映射表会好一些。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1071 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 19:17 · PVG 03:17 · LAX 11:17 · JFK 14:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.