sql - 我应该将贷款、采购和销售表非规范化为一张表吗？

Question

根据我在下面提供的信息，您能否就将单独的表非规范化为一个包含不同类型契约(Contract)的表是否是一个好主意给出您的意见？.. 赞成/反对的是什么？.. 有以前有人尝试过吗？.. 银行系统使用 CIF(客户信息文件)[master]，其中客户可能拥有不同类型的帐户、CD、抵押贷款等，并使用交易代码[类型]，但他们是否将它们存储在一张表中？

我有单独的表格用于贷款、购买和销售交易。每个表中的行都按以下方式连接到相应的客户:

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

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

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

场景:

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

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

Contracts.Capital DECIMAL(7,2) 

在借贷契约(Contract)中，它持有典当本金，在购买契约(Contract)中，它持有购买价格，在销售契约(Contract)中，它持有销售价格。

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

Answer 1

您的表秒设计更好，并且“规范化”了。

您的第一个设计是非规范化的!

您基本上遵循称为“子类型/父类(super class)型”的数据库设计/建模模式用于处理诸如交易之类的事情，其中​​有很多公共(public)数据和一些特定于每种交易类型的数据。

有两种可接受的建模方法。如果可变数据是最小的，那么您可以将所有内容保存在一个表中，并将交易类型特定的属性保存在“可空”列中。 (这基本上是你的情况，你做了正确的事!)。

另一种情况是“不常见”数据根据交易类型变化很大，在这种情况下，您有一个包含所有“常见”属性的表，以及一个包含每种类型的“不常见”属性的表“类型”。

然而，“贷款”、“购买”和“销售”作为交易有效。我认为 Inventory 是一个不同的实体，应该有自己的表格。本质上，“贷款”将添加到库存交易中，“购买”将库存状态更改为“可售”，“销售”将从库存中删除项目(或将状态更改为已售出)。一旦将一个项目添加到库存中，只有它的状态应该改变(它仍然是一个小部件、 fiddle 或其他什么)。