这个数据库模式是否正确？ （学期）
Is this database scheme correct? (ERM)
我正在为一个项目设计一个小型数据库，我不太确定我的设计是否一切正确，或者是否有需要解决的问题。
这是关于事件的管理。
特别是 table 参与者我不太确定，因为那里包含 user_id，同时也包含订单。 table 参与者对我来说很有意义，但一方面是因为只能由参与者创建评级，另一方面是为了将来的扩展（聊天等）。
感谢任何反馈。
将我们的意见归纳为原则。
- 避免同一关系有多个路径。
比如一个Participant属于Event，但是它也有很多Ticket属于TicketCategories，可以对应不同的Event。
- 避免冗余。
例如，OrderItem 中的所有内容都可以从 Order 的 Tickets 派生。
- 通过其他关系推导关系。
用户和事件通过他们的票证和票证类别相关联。参与者多余。
架构看起来像这样（"has many through" 表示连接）。
- 用户
- 有很多票
- 通过 Tickets 有很多 TicketCategories
- 通过 TicketCategories 有很多活动
- 有很多订单
- 事件
- 有很多 TicketCategories
- 通过 TicketCategories 有很多票
- 通过工单有很多用户
- 门票
- 属于用户
- 属于订单
- 属于票务类别
- 通过 TicketCategory 有一个事件
- 门票类别
- 属于事件
- 有很多票
- 通过工单有很多用户
- 订单
- 属于用户
- 有很多付款
- 有很多票
- 付款
- 属于订单
- 有一个用户通过订单
将用户链接到事件的参与者已消失。现在，用户和事件通过 TicketCategory 由他们的票证链接。如果您想获得特定于事件的用户信息，请像这样制作 key/value table。
- 事件用户信息
- 关键
- 值（理想情况下 JSON 存储任何内容）
- 属于用户
- 属于事件
- 唯一（键、用户、事件）
OrderItem 也不见了。其中的所有内容都可以从订单的票中派生。因为它属于 TicketCategory，所以意味着只能订购 Tickets。没有它，可能会订购其他东西。
您将来可能希望添加类似 OrderItem 的东西来记录有关订购该商品的具体细节（折扣代码、特殊说明、数量、实际销售价格），但在这种情况下，一张票将属于OrderItem 而不是 Order。
- 订单项
- 属于订单
- 有很多票
- 有一个用户通过订单
- 价格（出售时的价格）
- 折扣代码（特定于这些项目）
- 门票
- 属于 OrderItem
- 属于用户
- 属于票务类别
OrderItem.price 是我们确实需要冗余数据的一个很好的例子。这是下订单时的价格快照。例如，如果 TicketCategory.price 发生变化，您不希望现有订单的价格发生变化。
然后您可以通过让它们也属于 OrderItem 来订购其他东西。
这是关于事件的管理。
特别是 table 参与者我不太确定，因为那里包含 user_id，同时也包含订单。 table 参与者对我来说很有意义，但一方面是因为只能由参与者创建评级，另一方面是为了将来的扩展（聊天等）。
感谢任何反馈。
将我们的意见归纳为原则。
- 避免同一关系有多个路径。
比如一个Participant属于Event，但是它也有很多Ticket属于TicketCategories，可以对应不同的Event。
- 避免冗余。
例如，OrderItem 中的所有内容都可以从 Order 的 Tickets 派生。
- 通过其他关系推导关系。
用户和事件通过他们的票证和票证类别相关联。参与者多余。
架构看起来像这样（"has many through" 表示连接）。
- 用户
- 有很多票
- 通过 Tickets 有很多 TicketCategories
- 通过 TicketCategories 有很多活动
- 有很多订单
- 事件
- 有很多 TicketCategories
- 通过 TicketCategories 有很多票
- 通过工单有很多用户
- 门票
- 属于用户
- 属于订单
- 属于票务类别
- 通过 TicketCategory 有一个事件
- 门票类别
- 属于事件
- 有很多票
- 通过工单有很多用户
- 订单
- 属于用户
- 有很多付款
- 有很多票
- 付款
- 属于订单
- 有一个用户通过订单
将用户链接到事件的参与者已消失。现在，用户和事件通过 TicketCategory 由他们的票证链接。如果您想获得特定于事件的用户信息，请像这样制作 key/value table。
- 事件用户信息
- 关键
- 值（理想情况下 JSON 存储任何内容）
- 属于用户
- 属于事件
- 唯一（键、用户、事件）
OrderItem 也不见了。其中的所有内容都可以从订单的票中派生。因为它属于 TicketCategory，所以意味着只能订购 Tickets。没有它，可能会订购其他东西。
您将来可能希望添加类似 OrderItem 的东西来记录有关订购该商品的具体细节（折扣代码、特殊说明、数量、实际销售价格），但在这种情况下，一张票将属于OrderItem 而不是 Order。
- 订单项
- 属于订单
- 有很多票
- 有一个用户通过订单
- 价格（出售时的价格）
- 折扣代码（特定于这些项目）
- 门票
- 属于 OrderItem
- 属于用户
- 属于票务类别
OrderItem.price 是我们确实需要冗余数据的一个很好的例子。这是下订单时的价格快照。例如，如果 TicketCategory.price 发生变化，您不希望现有订单的价格发生变化。
然后您可以通过让它们也属于 OrderItem 来订购其他东西。