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

Question

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

1. 产品

   ID | Name | Price
   

2. 收货

   ID | Date | Quantity | Product_ID (FK)
   

3. 销售量

   ID | Date | Quantity | Product_ID (FK)
   

由于收货和销售是相同的，所以我正在考虑采用另一种方法：

1. 产品

   ID | Name | Price
   

2. Receivings_Sales（名称无关紧要）

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

列类型将标识它是收货还是销售。

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

谢谢！

Answer 1

我个人比较喜欢第一个选择，那就是，对于单独的表Sales和Receiving。

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

1) Inflexibility
2) Unnecessary filtering when use

首先是僵化。如果您的需求扩大了（或者您只是简单地忽略了它），那么您将不得不破坏您的架构，否则您将得到未标准化的表。例如，假设您的销售现在包括执行销售交易的销售员/人员，因此显然与之无关'Receiving'。而且，如果您进行零售或批发销售，该如何将其容纳在合并表中？折扣或促销怎么样？现在，我在这里识别明显的东西。现在，转到Receiving。如果我们想把我们的收货与我们联系起来Purchase Order怎么办？显然，采购订单详细信息（如PO编号，PO日期，供应商名称等）不会包含在以下内容中，Sales但显然与更为相关Receiving。

其次，在使用时进行不必要的过滤。如果已合并表，并且只想使用表的Sales（或Receving）部分，则必须通过后端程序或前端程序过滤掉接收部分。如果它是一个单独的表，则您一次只能处理一个表。

另外，您提到ORM，第一种选择最适合该工作，因为显然，与此相关的对象或实体应该与其他实体/对象不同。