电子票的数据库设计

Question

一个用户可以创建一个订单，一个订单可以用于多个电子票。每张票都需要在电子票表中拥有自己的行。此外，如果用户决定升级其 eTicket，则可以将后续订单分配给已经存在的 eTicket。

如果我有带有订单详细信息的标准订单结构，我如何将电子票与支付的订单关联起来？

我认为仅将订单分配给电子票是行不通的，因为如果订单是针对多张电子票并且每个电子票针对不同的事件，那么您怎么知道电子票针对的是哪个事件该信息已存储在订单详细信息行中？请记住...一个订单可以用于多张电子机票！

编辑

所以这就是我目前得到的......

订单

OrderId PK

产品

ProductId PK, EventId FK

订单详情

OrderDetailId PK， OrderId FK, 产品 ID FK, 数量

eTicketAssignment

OrderDetailId FK, eTicketId FK

电子票

eTicketId PK

因此，如果用户为特定活动购买了三张电子票，则在结账时会创建三张电子票，并且每一张都会分配给订单详细信息。还可以在存款和余额之间中断付款，并且通过订单详细信息将两个订单分配给同一个电子票。

现在我已经完成了这项工作，但我认为它有些地方不太对劲！电子票真的应该分配给订单明细吗？如果不是，那它还能去哪里？

编辑 2

在其核心，电子商务引擎需要能够销售任何东西，而 eTickets 代表了通过创建数据交付的产品的一个特例——所以我有点需要订单详细信息。此外，对于不代表固定住宿的电子票，订单详情中的数量给出了可以进入相应单人电子票的人数。当住宿固定时，例如在度假营地购买小木屋时，订单明细上的数量给出了小木屋的数量，每个小木屋都有自己的电子票。

这已经运行了一段时间...我想我只是在寻找一些关于设计的反馈，这似乎需要一些尴尬的查询。

例如，给定一些 eTicket，我如何确定它用于哪个事件？我需要加入从 eTicket 表到 product 表的三个连接，如果有多个订单分配给 eTicket，这将返回多行，这意味着我需要执行某种 TOP 1 子查询或聚合查询来获得价值。

Answer 1

也许是这样的？这样，如果 eTicket 发生变化，您可以将 ticket_parent 更新为之前的 ticket_id。

编辑 1

经过您的修改，以下是我的想法：

您不需要数量，因为它可以通过订单的电子票数来计算。我认为不需要详细的订单表，因为您可以将其汇总为一个订单。此外，您当前的设置不会跟踪电子票的更改。我将对图表进行的唯一修改是添加Product 表。我会提出这个事件是属于门票还是属于订单的问题，然后可能会将event_id 移动到order 表中。