数据库架构组织

Question

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

背景： 有一个活动日历，任何用户都可以随时注册参加任何活动。 稍后，但在该活动之前，其中一名管理员将介入并从注册的人员中选择一个“员工列表”，其余的将被放入“备用列表”中。

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

• UserEvent
  • 将用户映射到他们注册的活动。 并不暗示员工或 Alt 列表成员身份。
• 用户人员
  • 将用户映射到他们注册的活动，并且恰好正在配备人员。
• 用户Alt
  • 与 UserStaff 类似

问题就变成了两部分：

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

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

希望我已经说得足够清楚了，并提前致谢。

Answer 1

我将有下表：

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

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

Answer 2

这看起来不错，但您可能需要考虑将用户-事件关联表合并为一个，并在该表上有一列指示关联的目的，即事件、人员或 Alt。 这将有效地消除您在 UserEvent 表中描述的重复的需要，因为在大多数情况下，Staff 和 A​​lt 可以被视为 Event 的超集。

这种方法的一个好处是它允许存在多种类型的用户-事件关联，例如，如果您有一个用户是某个活动的工作人员但不是参与者，或者一个用户只是 Alt； 这种方法使您不必枚举所有可能的组合。 现在，如果您的设计明确指定只能拥有一组特定的用户参与类型，这可能会引入您不希望的分离程度； 您可能更愿意对用户对活动的参与级别设置明确的限制。 另一方面，如果您没有严格指定的集合，则该系统允许轻松添加更多参与角色（并且不会干扰现有的参与角色）。

Answer 3

不是对您问题的直接回答，但这是一个我喜欢的网站。 它有大量的示例模式。 我通常不会将它用作确定性的（当然），但有时它会给我一些我没有想到的想法。