我应该将 Loans、Purchase 和 Sales 表非规范化为一张表吗？答案

【问题标题】：Should I denormalize Loans, Purchases and Sales tables into one table?我应该将 Loans、Purchase 和 Sales 表非规范化为一张表吗？
【发布时间】：2011-03-04 17:35:57
【问题描述】：

根据我在下面提供的信息，您能否就将单独的表格非规范化为一个包含不同类型合同的表格是否是一个好主意给我您的意见？... 什么是赞成/反对的？...有以前有人尝试过吗？.. 银行系统使用 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)

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

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

【问题讨论】：

顺便说一句，这里的实际问题是什么？
同上。看不到你在问什么。
我要问的是：最好为每种类型的事务使用单独的表，还是更好地为所有类型设置一个事务表，以前做过，这将简化查询、更新和连接。 . 以前成功过吗？...等

标签： sql oracle informix denormalization

【解决方案1】：

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

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

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

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

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

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

【讨论】：

由于典当或购买的商品来自特定客户，并为其分配了唯一的序列交易编号，因此当铺应将商品转入库存，典当店想知道商品的历史，以前的交易编号等。当库存出售时，它可能会记录和存储买家的姓名、地址等，也可能是匿名的“CASH SALE”，但每件商品都带有原始交易编号的微标记，以便在重新处理时进行追踪出现在当铺或报告被盗。
当铺库存被定义为当铺将储存以供公众出售的所有物品。商品可以通过以下方式落入当铺库存： 1) 典当物品因未支付利息或客户未赎回而被客户没收。 2) 当铺从客户或其他实体购买商品。一些被没收或购买的物品，如黄金、白银、铂金、铑或其他贵金属，可能永远不会存入库存，因为当铺将直接将其出售给精炼厂，精炼厂将根据纯度和重量向典当行付款。

【解决方案2】：

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

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

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

【讨论】：

1.将四张表合二为一不是反规范化吗？ 2. 寻找确认。 3.忽略证据，因为我的设计更多地与我在“场景”中描述的真实场景相关，提高了性能并简化了程序逻辑。
@Frank - 我不确定。如果我在四个单独的表中包含家庭地址、邮寄地址、送货地址和帐单地址，并且我决定在一个地址表中添加一个额外的列来说明它是如何使用的，这会被视为非规范化吗？我会把它留给比我更专业的人。
到目前为止，我的表格合并到一个事务文件中已经产生了很好的结果！...更大的灵活性，代码简化，用户不必根据事务类型切换到不同的屏幕，并且性能大大提高..这是非规范化！.. 在处理少量行时，增加的存储使用量不是问题.. 这也避免了连接的费用！