数据库设计选择：订单属于发票或发票属于订单

Question

有一个网站用于销售实体产品......现在他们想要销售一些完全不同的服务之王....比如信用包收取用户帐户（购买产品）或购买短信..这样的东西

所以db过去看起来像这样

order : user_id  ,date , total_price 
order_items : order_id , item_id , quantity , price
invoice : order_id , price , settled 
Invoice_transactions : invoice_id , amount , date

基本上发票属于订单

现在他们想要销售服务，所以我们必须创建2 orders表

product_orders (it used to be orders)
service_orders 

现在我必须选择发票表的设计

我可以添加另外一个字段来表示订单的类型

invoice : order_id , order_type , amount
          1        , product    , 10000
          1        , service    , 10000

以某种方式感觉不对......或者我可以向订单添加发票ID

invoice :  order_type , amount , date
product_orders : invoice_id , date , total_price
service_orders : invoice_id , service_id , date , total_price

哪一个（如果有的话）似乎更合理的设计？ 这是产品表：

这是服务表的样子：

这里是订单（应该更改为产品订单）

这是service_order的样子

Answer 1

这完全取决于您想要实现的目标，客户可以一次购买吗？最常见的是您使用order_type的发票所做的事情，它将具有最少的重复

Answer 2

这就是我想要做的事情：

表types

type_id | name
      1 | product
      2 | service

表items对于产品和服务都有共同的列。

items: item_id, type_id FK(types.type_id), price, title, ...

使用FK products的表services和item_id以及两种类型都不常见的列（例如products.weight）。

将type_id列添加到orders表：

order : user_id, date, total_price, type_id FK(types.type_id)

将type_id列添加到表格order_items：

order_items: order_id, item_id, type_id, quantity, price

FK将是：

(order_id, type_id) -> orders(order_id, type_id)
(item_id, type_id) -> items(item_id, type_id)

对于那些FK，不可能在一个订单中混合使用不同的类型。

Answer 3

我认为产品订单和服务订单的共同点多于差异。在更大的商业和金融生态系统中，他们可能共享相同的角色/职能。所以我的第一直觉是为这两种订单设置一个表。

一对一表

另一种方法是只有一个order_表，其中一列指示哪个类型的命名类似于order_type_，其中包含sales或products等值。

将所有与产品相关的列移动到单独的子表product_info_。将所有与销售相关的列移动到单独的子表service_info_。我会将order_表作为两者的父级，尽管从技术上讲，我们有一对一的关系。对于任何给定的order_行，我们只有一行product_info_行或一行service_info_行。

这可以最大限度地减少数据库中的数据重复和应用程序中的编码。当您需要产品或服务详细信息时，您的应用代码会使用标记字段order_type_来适当地查询一个或另一个子表。

发票表链接到订单表。我假设两种类型的订单的发票工作几乎相同。

订单

中的所有字段

另一种选择是简单地在order_表中包含所有产品和服务字段。只需忽略服务订单的产品相关字段，并忽略产品订单的服务相关字段。不是最优雅的，但如果您的字段相对较少，并且可能在列名称前加上prod_和serv_，则这可能是切实可行的。我当然不止一次这样做过。