一种更好的实现事件票务系统数据库的方法答案

【问题标题】：A better way to implement event ticketing system database一种更好的实现事件票务系统数据库的方法
【发布时间】：2022-01-05 05:30:52
【问题描述】：

我正在一个网站上添加票务功能，用户可以在该网站上宣传他们的活动。我想添加一个票务功能，用户可以为活动创建票，然后用户可以购买这些票。我想出了以下数据库结构（它不是很整洁，但我希望它能解释我想要做什么）。所以我的问题是这是正确的方法吗？还是我以后会遇到这个问题？

【问题讨论】：

没有足够的信息来确定这一点。大多数事情看起来都不错，但我不确定不同 event_(type|id) 关系的区别是什么；在booked_tickets 中使用email 作为外键将是一个坏主意（即使对客人来说也是如此），它可能应该被2 个合成ID 字段替换；它不是很清楚你是如何想象门票的。qty 事情正在解决（或者你是否/如何计划执行）；这只是我想到的几件事
这类问题总是有不止一种解决方案，而且随着系统的发展，最好的解决方案会有所变化。目前这似乎还可以。它会在五年内处理好负载吗？谁能说？
感谢@Raxi 的回复。不同的事件类型有不同的数据库表（这没有意义，这是以前的开发人员设计的方式，所以无法改变）。所以首先我必须查看是哪种类型的事件，然后我查找与之关联的表以将其 id 作为参考。而且我不会将电子邮件作为参考。只是图表不符合标准。对于数量，它将由创建门票的人决定。每次购买后将减少金额。
@TangentiallyPerpendicular 我猜你是对的。我现在应该按原样实施，然后等待有什么问题来改进它。
一般来说，为每个可能的 eventdetailtable 设置 1 个 id 字段比使用 1 个可以引用多个表的 id 字段要好得多。所有不相关的都可以为空；并且您可以向表中添加一个约束，使其/仅/其中一个可能具有值（或您决定的特殊组合）。

标签： php mysql sql database

【解决方案1】：

关于实施

阅读一些关于设计模式的内容，特别是 observer design pattern 适合您的案例：

因为它是为观察者设计模式的purpose 编写的：

要实现对象的发布/订阅行为，每当“主题”对象更改其状态时，都会通知附加的“观察者”。用于缩短耦合对象的数量，改为使用松耦合。

在实现上述设计模式后，您可以简单地通知所有实体及其相应的控制器执行您想要的操作，就像：

事件到期时发送通知
当一个事件改变了它的状态并且你想根据这个改变做一些动作时。
其他任何需要监督的操作

此外，如果您的活动具有相同的创建过程但使用不同的供应，您可以使用builder design pattern 来创建它们。

例如：
您正在创建的所有事件都需要注册信息，需要通知用户，需要触发日志，需要... 您可以使用此模式来创建事件。

可能还有其他适合您的项目的设计模式，但您必须根据您未提及的其他要求提取它们。

关于您的 ERD：

purchased ticket 表必须是数据透视表，因此 UID 可以在此表中结算（不是ticket），有关付款的信息（paied_price，transaction_id，...）可以在另一个表中包含所有付款信息（比如payments），用户信息保留在user 表中（信息如电子邮件。）

但无论如何这是我的建议，您绝对可以将您的数据模型与其他系统的数据规范化到您想要的级别并创建规范化表。

【讨论】：

感谢@behzad 的回复。我需要票证中的 uid，以便我可以获取创建票证的用户/组织者。您建议的设计模式很有趣，我很想学习它们，但在当前系统中实现它们会很痛苦，因为它不使用任何框架或任何类型的模式。