zoukankan      html  css  js  c++  java
  • 从一个审批需求看数据库设计——联合主键的使用

    最近工作挺忙,已经接近996了,所以博客更新也少了。今天忙里偷闲,分享一个最近遇到的一个数据库设计问题。业务需求是:

    • 针对一条人员信息的数据进行审批操作
    • 在进行审批时要看到审批前后数据的修改
    • 同一人员的审批数据只能存在一条
    • 审批通过后数据在正式表中生效
    • 审批通过后保存审批结果数据

    业务逻辑本身并不复杂,我们可以建一个跟正式表完全相同的临时表来存储修改的数据,再增加一个审批结果来标识这条数据。

    假如正式表为:

    ID(pk) INFO1 info2 ...
    00001 test test ...

    那么我们临时表可以设计为

    ID(pk) info1 info2 ... AUDIT_RESULT
    00001 updated updated ... pass

    这样的设计符合直觉,实现起来也很简单,但问题是这个方法的扩展性不够好。原因是正式表的字段可能有很多,这些字段的类型也千差万别。假如以后加入了新功能需要对正式表的部分字段进行修改审批,当前的临时表就不能满足了。因为临时表是以id为主键的,如果继续使用临时表,则之前的审批结果就无法保存了。为了满足今后的扩展,临时表需要重新设计。

    临时表的基础上加一个字段AUDIT_TYPE ,把AUDIT_TYPE设置为主键。表结构如下:

    ID(pk) AUDIT_TYPE(pk) INFO1 INFO2 ... AUDIT_RESULT
    00001 01 updated updated ... pass
    00001 02 updated updated ... reject

    设置AUDIT_TYPE以后就可以区分出各种类型的审批,方便针对其他类似的需求进行扩展。当然实际使用的时候应该考虑业务的要求,如果业务没有潜在的扩展需求用第一个方法也是可行的。

    这个设计思路可以推广到其他数据库的设计。每个月备份正式表的数据,我们就可以加一个月份作为联合主键。举个例子:

    ID(pk) MONTH(pk) INFO1 INFO2 ...
    00001 201801 test test ...

    类似的例子还有很多,这里就不多费口舌了。

  • 相关阅读:
    HDU 5492 Find a path
    codeforce gym 100548H The Problem to Make You Happy
    Topcoder SRM 144 Lottery
    codeforce 165E Compatible Numbers
    codeforce gym 100307H Hack Protection
    区间DP总结
    UESTC 1321 柱爷的恋爱 (区间DP)
    HDU 4283 You Are the One (区间DP)
    HDU 2476 String painter (区间DP)
    UESTC 426 Food Delivery (区间DP)
  • 原文地址:https://www.cnblogs.com/rever/p/8360994.html
Copyright © 2011-2022 走看看