【发布时间】：2020-03-29 16:18:27
【问题描述】：
我有一个包含以下实体的数据库：
1. User entity
2. Event entity (musical concert etc.)
3. Ticket entity
3. Notification entity
- 通知实体与Ticket有直接关系 和事件（1：N [票证/事件：通知]）。
- 通知将是 存储在数据库中，用户可以通过 通知选项卡。
- 可以通过相关的通知通知用户 到他的票（例如“我们刚刚将您的票寄给了您！”）或关于 一些活动（例如“活动 xy 即将到来！预订您的位置！”）。
我一直在考虑三种可能的解决方案：
a) 通知实体具有以下结构：
id serial PRIMARY KEY,
.
.
ticketId integer REFERENCES tickets(id),
eventId integer REFERENCES events(id))
userId integer REFERENCES users(id) // this is present in all three solutions;
这样，通知实体同时拥有两个外键，但一次只填充其中一个（eventId 或 ticketId），另一个永远为空。
b) 通知实体只有与通知本身相关的列，它不包含任何外键（userId 除外）。
将该关系提取到另外两个具有这种结构的关系映射表中（对于Notification-Ticket关系，同样适用于Notification-Event，除了外键引用事件）：
id serial PRIMARY KEY,
notificationId integer REFERENCES notifications(id),
ticketId integer REFERENCES tickets(id));
这样，我们创建了类似于接口的东西，并且不让 Notification 实体知道任何有关关系的信息（它只有与通知本身和 userId 相关的属性），并且我们有两个额外的表来映射关系。
c) 将通知实体分成两个不同的实体
（TicketNotification，EventNotification），它们每个都有相同的属性，但在外键列中有所不同。
- TicketNotification - foreign key references ticketId
- EventNotification - foreign key references eventId
这样，我们有两个具有相同属性的表，只是在一列中有所不同，这对我来说似乎不是很干。
我会感谢任何形式的帮助和可能的解决方案，我可能完全离开并从一个不好的角度看待它。谢谢。
【问题讨论】：
-
通知是否可以同时与门票和事件相关，或者仅与其中一个相关？如果是后者，您可能希望添加“通知类型”作为 Notification 的属性或相关的 NotificationType 表，然后使用选项 a) 作为数据模型，因为这样您就可以轻松地仅过滤事件或票务通知。如果您将来可能有更多与通知相关的实体，而不仅仅是票证或事件，您可能希望将其建模为 NotificationRelationship 表，该表具有关联实体的“类型”和外键。
-
我现在意识到这不是我能提供的最好的例子，因为这里的实体 Event 和 Ticket 以某种方式相互关联（您购买了活动的门票）。这只是为了简单起见，但在我的真实案例中，这些实体根本不相关，因此请考虑这是“一个或另一个”案例场景。谢谢你的回答。
标签： sql database database-design relational-database entity