代码之家  ›  专栏  ›  技术社区  ›  Pat James

我是否应该将贷款、购买和销售表非规范化为一个表?

  •  2
  • Pat James  · 技术社区  · 5 年前

    根据我在下面提供的信息,您能否就将单独的表反规范化为一个包含不同类型合同的表这一点发表您的看法?。。什么是赞成/反对?。。以前有人试过吗?。。银行系统使用CIF(Customer Information File)[master],其中客户可能有不同类型的账户、CD、抵押等,并使用交易代码[类型],但它们是否将它们存储在一个表中?

    customer.pk_id SERIAL = loan.fk_id      INTEGER; 
                          = purchase.fk_id  INTEGER; 
                          = sale.fk_id      INTEGER;  
    

    由于这些表中有太多共同的属性,它们围绕着相同的商品:典当、买卖,我尝试将它们合并到一个名为“合同”的表中,并添加了以下列:

    Contracts.Type char(1) {L=Loan, P=Purchase, S=Sale}
    

    脚本:

    客户最初典当商品,支付几笔利息,然后决定将商品出售给典当行,典当行随后将商品放入库存,并最终将其出售给另一位客户。

    我设计了一个通用表,例如:

    Contracts.Capital DECIMAL(7,2) 
    

    在贷款合同中,它持有当押本金,在购买时持有购买价款,在出售时持有出售价款。

    这个设计是个好主意还是我应该把它们分开?

    2 回复  |  直到 12 年前
        1
  •  4
  •   James Anderson    14 年前

    你的桌子第二个设计更好,而且是“标准化”的。

    您基本上遵循一种称为“子类型/超类型”的数据库设计/建模模式 用于处理事务之类的事务,其中有许多公共数据和特定于每个事务类型的一些数据。

    有两种公认的方法来模拟这一点。如果变量数据最小,则将所有内容保存在一个表中,事务类型specfic属性保存在“nullable”列中(这基本上是你的情况,你做了正确的事情!)。

    另一种情况是“不常见”数据因事务类型的不同而变化很大,在这种情况下,您有一个包含所有“常见”属性的表,每个类型都有一个包含该“类型”的“不常见”属性的表。

    然而,虽然“贷款”、“购买”和“销售”是有效的交易。我认为库存是一个不同的实体,应该有一个自己的表。实质上,“贷款”wll添加到库存交易,“采购”wll将库存状态更改为可销售,“销售”wll从库存中删除项目(或将状态更改为已销售)。一旦一个项目被添加到库存中,只有它的状态应该改变(它仍然是一个小部件,小提琴或者别的什么)。

        2
  •  1
  •   duffymo    14 年前

    这里有问题吗?你只是想确认它是可以接受的吗?