根据我在下面提供的信息,您能否就将单独的表格非规范化为一个包含不同类型合同的表格是否是一个好主意,给我您的意见?。赞成/反对者是什么?..有人尝试过吗?银行系统使用CIF(客户信息文件)[母版],其中客户可能具有不同类型的帐户,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)
在贷款合同中,它包含典当本金额;在购买中,它包含购买价格;在销售中,它包含销售价格。
这个设计是一个好主意还是我应该将它们分开?
您的表第二设计更好,并且被“规范化”。
您的第一个设计是非规范化设计!
您基本上是在遵循一种称为“子类型/超类型”的数据库设计/建模模式来处理诸如事务之类的事务,在事务中有很多公共数据,并且每种事务类型都有一些特定数据。
有两种方法可以对此进行建模。如果变量数据很小,则将所有内容都保存在单个表中,并且“ nullable”列中保存有事务类型特定属性。(从本质上讲,这是您的情况,您做对了!)。
另一种情况是,“不常见”数据随事务类型的不同而有很大差异,在这种情况下,您有一个表,其中包含所有“常见”属性,每种类型的表中都包含该“类型”的“不常见”属性。
但是,“贷款”,“购买”和“出售”作为交易有效。我认为广告资源是一个不同的实体,应该有一个单独的表格。本质上,“贷款”将添加到库存交易中,“购买”将库存状态更改为“可售”,而“销售”将从库存中删除物料(或将状态更改为已售出)。将商品添加到库存后,其状态仅应更改(它仍然是小部件,小提琴或其他任何东西)。