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

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 item_id和两种类型不常见的列（如products.weight ）列出products和services 。

将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 order_type_ 。

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

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

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

订单中的所有字段

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