mysql - 在多级识别关系中，在其孙子中创建祖 parent 键、主键是否正确？

Question

问这个here几天前，但还没有得到很多浏览，更不用说回复了，所以我重新发布到 stackoverflow。

我正在为 session 票务系统建模数据库。在此系统中，与会者是属于 session 的与会者组的成员。这些关系具有识别性，因此 FK 必须是相应子项中的 PK。

我当前的型号:

问:在 attendee 表中将 attendeeGroupConferenceId FK 作为 PK，作为 MySQL Workbench 已经自动为我设置了吗？

一方面，通过将其保留在那里以便在“ checkin ”时快速关联，可以提高性能。 但是，这并不是绝对必要的，因为 id、attendeeGroupId 的组合以及 conferenceId 的相应查找相应的 attendeeGroup 表就足够了。 (因此成为冗余数据。)

对我来说，感觉它可能违反了某种形式的标准化，但我计划保留它以提高速度，如上所述。我只是好奇正确的设计对于是否赋予它 PK 地位有何说明。

Answer 1

您的 attendee 表中绝对不需要 attendeeGroupConferenceId。这是多余的，请注意候选键是 (attendeeGroupId, personId) 的组合，而不是单独的 attendeeGroupConferenceId。表 attendee 似乎也违反了 Second normal form (2NF)就这样。

我的建议是删除属性attendeeGroupConferenceId。在任何情况下，您都可以连接查询中的表来获取额外的信息，而不是保留额外的属性。