【问题标题】:DB Schema Organization数据库架构组织
【发布时间】:2010-11-05 16:37:18
【问题描述】:

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

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

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

  • 用户事件
    • 将用户映射到他们注册的事件。不暗示员工或 Alt 列表成员。
  • 用户员工
    • 将用户映射到他们注册的活动,也恰好是人员配备。
  • 用户Alt
    • 类似于 UserStaff

问题就变成了两部分:

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

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

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

【问题讨论】:

    标签: database database-design schema table-relationships


    【解决方案1】:

    我会有以下表格:

    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”之一。

    【讨论】:

    • 另一个有趣的想法。很高兴知道我还有更多的事情要考虑。
    • 其实我越想这个,我越喜欢“组合表格”的方法,因为它允许小组在以后轻松添加/更改注册类型。跨度>
    • 是的,这当然很实用; EventRegistration 和 ParticipantType 之间存在强制的一对一映射,尽管这让我有点担心。如果你想要完全脱节的参与怎么办?例如,您的用户是员工,但不是活动参与者?来自 EventRegistration 的外部引用意味着您只能为每个用户事件实例拥有一种类型的用户事件参与。
    • @McWafflestix:确实如此,但在这种情况下,这不会成为问题,因为单个用户只会有一个参与类型。它比我提到的要复杂一些,特殊人员有需要履行的特殊角色(例如组长或收银员),并且是多对多的。
    • 活动中的用户“角色”在他们注册后“稍后”分配。使用此模型,您将如何在初始注册和后续角色分配之间填充 EventRegistration.ParticipantTypeID?我建议不要将 EventRegistration.ParticipantTypeID 设为可为空的列,因为它们的状态不是“未知”——它只是未分配。相反,将“未分配”行添加到表 ParticipantType。
    【解决方案2】:

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

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

    【讨论】:

    • 有趣。这将解决我想象的问题,并将所有内容整合到一个地方。谢谢。
    • 我什至拒绝打败模拟羊... :-)
    【解决方案3】:

    不是直接回答您的问题,而是here's a site I like。它有大量(和大量)示例模式。我通常不会将其用作确定性(当然),但有时它会让我对我没有想到的事情有所了解。

    【讨论】:

    • 那是史诗。感谢您的链接。
    猜你喜欢
    • 2014-06-22
    • 1970-01-01
    • 1970-01-01
    • 2018-07-15
    • 1970-01-01
    • 1970-01-01
    • 2020-10-19
    • 2017-09-09
    • 2010-09-11
    相关资源
    最近更新 更多