使用哪个外键引用表？答案

【问题标题】：Referring table using which foreign key?使用哪个外键引用表？
【发布时间】：2011-12-14 19:07:15
【问题描述】：

student 提出一个新的topic。接受或拒绝topic 取决于adviser。如果他接受topic，顾问将监督student 和topic。

现在这就是我的目标。

meeting 安排在student 和adviser 之间，用于与该主题相关的讨论。

如果我创建一个meeting_table。我应该如何推荐meeting？关于被选中的topic？如果是这种情况，那么 topic_id 将是外键。

或者我应该使用advisor_id 和student_id 作为外键来引用它？

哪种方法更简单？因为我将在完成数据库设计后制作一个 Web 应用程序。

【问题讨论】：

学生和导师可以通过多个主题建立联系吗？同一主题可以成为多个学生/顾问关系的基础吗？会议总是只针对一个主题吗？
@Ted Hopp 每个学生的主题都是独一无二的。类似的话题将被拒绝。一个学生只能有一名顾问。顾问可以监督多个学生（前提是他们每个人都有独特的主题）
如果没有一个答案能解决您的问题，也许您应该澄清问题所在。

标签： mysql database database-design dns erd

【解决方案1】：

基于my answer to your previous question，我会像这样扩展该ERD：

在安排会议之前，学生需要有一个主题和一个顾问。通过加入会议 -> 学生 -> [顾问|主题]，可以找到主题和顾问。

【讨论】：

【解决方案2】：

如果会议涉及一个主题、一个学生和一个顾问，它不应该引用所有三个吗？或者对于更通用的会议模式，我会使用类似的东西：

ATTENDEES
id
name
role              ; i.e. 'student', 'advisor', etc

ROOM
id
description

TOPIC
id
description

MEETING
id
topic_id            ; FK to TOPIC.id
room_id             ; FK to ROOM.id
description

MEETING_ATTENDANCE
attendee_id         ; FK to ATTENDEE.id
meeting_id          ; FK TO MEETING.id

此架构将允许任意数量的参与者（因此您可以有一个顾问和三个学生，等等）。对于奖励积分，它还包含会议室 ID。

【讨论】：

引用所有三个主题、学生和顾问代表冗余信息，意味着非规范化模式。
我认为角色在这个模型中是一件好事，但它属于 meeting_attendance 表而不是参加者表。可以想象，一个人可以在不同的会议中担任不同的角色。
@Randy：当然，这将是一个合理的调整，具体取决于您的需要。角色可以是一个人（即学生、教师等）或与会议相关的人（即演示者、与会者、供应商等）的属性；所以根据您的情况，您可能需要移动“角色”（或有多个）
您需要在架构中添加一个表来表示学生、顾问和主题之间的关系。根据 OP 的描述，无论有没有安排任何会议，都需要记录这种关系。
@TedHopp：当然，功能齐全的数据库需要更多支持表。但由于这个问题是专门针对会议关系的，所以我只在这里解决。

【解决方案3】：

我建议使用 meeting_id 进行会议，然后再使用 meeting_id 和 topic_id 进行另一个表 meeting_topic - 这也将允许多个主题，具体取决于您的唯一性规范。此外，由于许多人可能会参加同一个会议，例如 meeting_attendee 至少有两行，一是学生，一是顾问。像这样：

meeting
----------
meeting_id
meeting_date
location_id (?)

topic
----------
topic_id
description

meeting_topic
-----------
meeting_id
topic_id

meeting_attendee
-----------
meeting_id
attendee_id

【讨论】：

topic 表中应该有字段将主题与学生和顾问相关联。这种关系独立于安排的任何会议而存在。如果这样，meeting_attendee 表将是多余的。
如彩色文本中所述，这有点宽泛，因为它允许多人参加一个会议，以及该会议的多个主题。

【解决方案4】：

根据给出的信息，在我看来，将会议引用到该主题效果很好。但是，这是否最简单取决于您期望的查询（包括它们的相对频率）。

【讨论】：

【解决方案5】：

我的餐桌设计：

Student (id, name)

Advisor(id, name)

Topic(id, name, created_by(foreign key id of student), advisor(foreign key id of advisor))

Meeting(id, name, schedule, topic (foreign key id of topic))

这是考虑到会议中一名学生和一名顾问的最简单的数据库设计。

【讨论】：

这不是标准化的。在表 Meeting 中，student 和 advisor 值是 topic 的函数（通过主题表）。