Question

我目前正处于构建计划网络应用程序（用于活动的志愿者人员配置）的计划阶段，我对那些有更多经验的人提出了一个问题。

背景：有一个事件日历，任何时候任何用户都可以注册任何事件。在稍后的时间，但在该事件发生之前，其中一个管理员将介入并从注册的人员中选择“人员列表”，其余的将被放入“备用列表”。

到目前为止，我一直在想的是会有一个事件表，一个用户表，然后是另外三个：

UserEvent
- 将用户映射到他们注册的活动。并不意味着工作人员或Alt列表成员资格。
UserStaff
- 将用户映射到他们注册的活动，并恰好配备人员。
UserAlt
- 与UserStaff类似

然后问题变成两部分：

这是一个很好的方法吗？
这三个关联表中的每一个都应该具有用户ID和事件ID吗？

第二个问题实际上是我想要讨论的问题。这似乎是很多重复的材料（UserStaff或UserAlt中的所有内容都将始终在UserEvent中），所以我考虑为UserEvent表创建一个唯一的键，除了复合键，还有其他表（UserStaff和UserAlt）将参考。从好的方面来说，重复的内容较少，在不利的一面，有一个中间表（UserEvent），几乎每个查询都需要以这种方式引用。

希望我已经足够清楚，并提前感谢。

Answer 1

这似乎很好，尽管您可能需要考虑将用户 - 事件关联表合并为一个，并在该表上有一个列，用于指示关联的目的，即事件，员工或Alt。这样可以有效地消除对UserEvent表中描述的重复的需要，因为在大多数情况下，Staff和Alt可以被认为是Event的超集。

这种方法的一个好处是它允许存在多种类型的用户 - 事件关联，例如，如果您的用户是事件但不是参与者，或者用户只是Alt键;这种方法使您不必枚举所有可能的组合。现在，如果您的设计明确指定您只能拥有某组用户参与类型，则可能会引入您不想要的分离级别;您可能希望对用户可能对某个事件具有的参与级别设置有明确的约束。另一方面，如果您没有严格指定的集合，则此系统允许轻松添加更多参与角色（并且不会干扰现有的参与角色）。

Answer 2

我会有以下表格：

User (UserID, firstname, lastname, etc.)
Event (EventID, Name, Date, Location, Capacity, etc.)
EventRegistration (EventRegistrationID, UserID, EventID, ParticipantTypeID, etc.)
ParticipantType (ParticipantTypeID, Name)

ParticipantType.Name是“参与者”或“员工”之一。

Answer 3

不是您问题的直接答案，而是here's a site I like。它有大量（和吨）的样本架构。我通常不会将它当作权威（当然），但有时它会让我对我没想到的东西有所了解。

DB Schema Organization

3 个答案: