将两个数据库表合二为一？答案

【问题标题】：Turn two database tables into one?将两个数据库表合二为一？
【发布时间】：2014-09-04 17:34:10
【问题描述】：

在将关系数据库建模为库存管理系统时，我遇到了一些麻烦。目前，它只有 3 个简单的表：

产品
```
ID | Name | Price
```
收货
```
ID | Date | Quantity | Product_ID (FK)
```
销售
```
ID | Date | Quantity | Product_ID (FK)
```

由于接收和销售是相同的，我正在考虑一种不同的方法：

产品
```
ID | Name | Price
```

Receivings_Sales（名称无关紧要）

ID | Date | Quantity | Type | Product_ID (FK)

列类型将识别它是接收还是销售。

谁能帮我选择最佳方案，指出这两种方法的优缺点？第一个似乎是合理的，因为我正在以 ORM 方式思考。

谢谢！

【问题讨论】：

他们真的一样吗？
我会说他们是。他们为什么不呢？我感谢任何 cmets/建议
那为什么他们的名字不一样呢？
因为它们是两个使用相同属性的不同操作...
DBA SE 专为您正在寻找的答案而设计。我建议您在那里问它或请求迁移它。

标签： sql database database-design orm

【解决方案1】：

如果这些表确实并且总是相同（我有疑问），然后将统一表命名为更通用的名称，例如“InventoryTransaction”，并且然后对其中一种交易类型使用负数：可能是销售额，因为这样可以在跟踪手头库存方面正确标记您的库存。

【讨论】：

谢谢你，乔尔！为什么它们不一样？设计（非常）简单的库存管理系统有什么更好的方法？
@LarissaLeite 系统随着时间的推移不断发展壮大。虽然它们现在可能相同，但您最终可能会发现，您需要在收据上保留一些与销售信息不同的信息。
谢谢，乔尔。似乎有道理。虽然，现在，我尽量保持简单，因为这只是我尝试集成 Hibernate 和 Java/JSF 的练习。

【解决方案2】：

我个人更喜欢第一个选项，即将Sales 和Receiving 分开表格。

选项 2 或将两个表合并为一个的两个最大缺点是：

1) Inflexibility
2) Unnecessary filtering when use

首先是不灵活。如果您的需求扩大了（或者您只是忽略了它），那么您将不得不分解您的架构，否则您最终会得到非规范化的表。例如，假设您的销售现在包括进行销售交易的销售员/人员，因此显然它与'Receiving' 无关。如果您进行零售或批发销售，您将如何在合并表中适应这种情况？折扣或促销怎么样？现在，我在这里识别出明显的东西。现在，让我们去Receiving。如果我们想将我们的接收绑定到我们的Purchase Order 怎么办？显然，采购订单详细信息如 P.O.号码，邮政编码日期、供应商名称等不在Sales 之下，但显然与Receiving 相关。

其次，关于使用时不必要的过滤。如果您已合并表并且只想使用表的Sales（或Receving）部分，那么您必须通过后端或前端程序过滤掉接收部分。而如果它是一张单独的桌子，您一次只需要处理一张桌子。

此外，您提到了ORM，第一个选项最适合该努力，因为显然一个对象或实体应该与其他实体/对象不同。

【讨论】：

【解决方案3】：

标题相同的事实无关。因为标题相同而寻求使用单个表格是误解。

-- person [source] loves person [target]
LOVES(source,target)

-- person [source] hates person [target]
HATES(source,target)

每个基表都有一个对应的谓词，也就是描述应用情况的填充-the-[named-]blanks 语句。基表包含构成真实语句的行。

每个查询表达式通过 JOIN、UNION、SELECT、EXCEPT、WHERE 条件等组合基表名称，并有一个相应的谓词通过（分别）AND、OR、EXISTS 组合基表谓词， AND NOT、AND 条件等。查询结果包含构成真实语句的行。

这样一组满足谓词的行是一个关系。没有其他理由将行放入表中。

（这里的其他答案必须解决您的一个表可能具有的谓词的建议和后果。但是，如果您由于其谓词而没有提出该表，那么您为什么要提出它？答案是，既然不是谓词，就没有充分的理由。）

【讨论】：