代码之家 › 专栏 › 技术社区 › nilamo

数据库架构组织

table-relationships schema database-design database

nilamo · 技术社区 · 15 年前

我目前正处于计划阶段,正在构建一个计划Web应用程序(用于活动的志愿者人员配置),对于那些有更多经验的人,我有一个问题要问。

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

到目前为止,我一直在想,会有一个事件表、一个用户表,然后还有三个:

用户事件
- 将用户映射到他们注册的事件。不意味着工作人员或备选名单成员。
用户工作人员
- 将用户映射到他们注册的事件,并且碰巧也是人员配备。
用户名
- 类似于用户工作人员

然后问题变成两部分:

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

第二个问题真的是我希望看到讨论的问题。这看起来像是大量重复的材料(userstaff或useralt中的所有内容都将始终在userevent中),所以我考虑为userevent表创建一个唯一的键,除了复合键之外,其他表(userstaff和useralt)将引用它。另一方面,复制内容较少,另一方面,中间表(userevent)几乎需要在每个查询中以这种方式引用。

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

3 回复 | 直到 15 年前

D'Arcy Rittich 15 年前

我想要下表:

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

参与者类型。名称是“参与者”或“员工”之一。

Paul Sonier 15 年前

虽然您可能希望考虑将用户-事件关联表组合为一个表,并在该表上有一列指示关联的目的,即事件、人员或alt,但这似乎很好。这将有效地避免在用户事件表中描述的重复,因为人员和alt可能是在大多数情况下被认为是事件的超集。

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

JP Alioto 15 年前

不是你问题的直接答案,但是 here's a site I like . 它有大量的示例模式。我通常不会把它当作决定性的东西(当然),但有时它会给我一个关于我没有想到的事情的想法。