1

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

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

到目前为止，我一直在想的是会有一个 Event 表、一个 User 表，然后是另外三个：

  • 用户事件
    • 将用户映射到他们注册的事件。既不暗示员工也不暗示 Alt 列表成员资格。
  • 用户工作人员
    • 将用户映射到他们注册的事件，也恰好是人员配备。
  • 用户Alt
    • 类似于 UserStaff

那么问题就变成了两部分：

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

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

希望我已经足够清楚了，并在此先感谢。

4

3 回答 3

2

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

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

于 2009-06-24T22:20:56.100 回答
2

我将有以下表格：

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

ParticipantType.Name 是“participant”或“staff”之一。

于 2009-06-24T22:22:12.693 回答
1

不是直接回答您的问题，但这是我喜欢的网站。它有大量（和大量）示例模式。我通常不会将其用作明确的（当然），但有时它会让我对我没有想到的事情有所了解。

于 2009-06-24T22:26:59.487 回答