3

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

我有单独的表用于贷款、采购和销售交易。这些表中的每一个的行以下列方式连接到其对应的客户：

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)

在贷款合同中，它持有典当本金，在购买中持有购买价格，在销售中持有销售价格。

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

4

2 回答 2

4

您的第二个表设计更好，并且是“标准化”的。

你的第一个设计是非规范化的！

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

有两种公认的方法来对此进行建模。如果变量数据最小，您将所有内容保存在单个表中，事务类型特定属性保存在“可空”列中。（这基本上是你的情况，你做了正确的事情！）。

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

然而，虽然“LOAN”、“PURCHASE”和“SALE”作为交易有效。我认为 Inventory 是一个不同的实体，应该有自己的表格。本质上，“LOAN”将添加到库存交易中，“PURCHASE”将库存状态更改为可销售，“SALE”将从库存中删除项目（或将状态更改为已售）。一旦一个项目被添加到库存中，只有它的状态应该改变（它仍然是一个小部件、小提琴或其他东西）。

于 2010-06-28T01:49:43.957 回答
1

我会争辩说它不是非规范化的。我没有看到重复的组；所有属性都取决于唯一的主键。对我来说听起来是个不错的设计。

这里有问题吗？您只是在寻找可以接受的确认吗？

假设性地，如果压倒性的共识是您应该为每种类型恢复为单独的表，您会怎么做？你会忽略你自己经验中的证据（更好的性能，更简单的编程）并听从 Stackoverflow.com 的建议吗？

于 2010-06-17T01:32:13.440 回答