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

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

1) Inflexibility
2) Unnecessary filtering when use

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

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

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