在表之间建立一对一关系的理由

Question

如果我有两种不同类型的用户，父母和子女。他们有相同的领域，但是一个孩子与考试有一对多的关系，父母不存在这种关系。

父母和孩子最好是作为单个表建模还是组合？

如果我有两种不同类型的用户，父母和孩子，该怎么办？除了属于学校的孩子（学校有很多孩子）外，它们是相同的。

再次，父母和孩子最好是作为单个表建模还是组合？

Answer 1

父母和儿童都是毫无疑问的人。你永远不应该将它们放在单独的表格中。

只有时间将它们分开：如果孩子成为父母会怎么样？

父母很容易生孩子，因为你需要一个关系表。 Als关系表是建立学校会员资格的正确方法。

所以表格在这里：

person
is_child_of (many to many, join table) --> relations between persons can be is_parent_of

简单明了

记住：成为一个孩子是一个人与人之间的关系。 如果需要，你会如何塑造孙子？又一张桌子？还有个曾孙子？

并且你很好，并且为很多“种类”关系制作了很多桌子，突然之间你想要你必须添加一个字段（出生日期）或改变字段格式：你必须在所有不同的表格中进行。

Answer 2

  

他们有相同的字段，但是Child与考试有一对多的关系

即使字段相同，不同的约束 ¹ 意味着您正在处理逻辑上独立的实体。如果没有其他因素，应将单独的实体放入单独的物理表中。

然而，可能有相反的理由。例如，如果有一个密钥需要在父项和组合的子项中是唯一的，或者还有另一个表需要引用它们等等...

如果是这种情况，则逻辑上“父”和“子”都继承自“人”，包含公共约束（和字段）。这种“继承”可以通过将整个层次结构存储到单个表中（并将未使用的“部分”设置为NULL），或者将所有三个“类”分成它们自己的表，并引用“基类”来表示。继承的类“，例如 ² ：

PERSON_ID在所有父母和孩子中都是独一无二的。除此之外，OTHER_TABLE可以直接引用它，而不必单独引用PARENT_ID或CHILD_ID。

---

¹ 在这种情况下是外键。

² 一个非常简化的模型，它只是说明了上述要点，并没有尝试对您在问题中提到的所有内容进行建模

Answer 3

您在问题中描述了三个不同的实体 - “父母”，“儿童”和“考试”。你已经展示了三者在彼此之间的关系如何不同。

根据你问题的所有内容，我会说你有三个实体，你应该在数据库中设置它们。也就是说，父母和孩子应该有单独的表。

Answer 4

我会把孩子分成一张单独的桌子，原因很简单，父母可能有很多孩子（如果不是现在，也许将来可能）。

除了目前的需求之外，考虑将来可能发生的事情也很重要，即使它现在没有意义。您可能有两个父母用户想要管理一个孩子和该孩子的考试。

考虑最可能的未来功能要求，并考虑到它们的程序。

Answer 5

如果您的系统中的项目建模方式不同，我会说它们应该是不同的表格。仅仅因为父母和孩子都具有相似的属性（姓名，年龄等），并不意味着他们将始终与数据库中的其他实体具有相同的关系。您可以将父级和子级放在同一个表中，其中包含与父级相关的列，但这只会导致在尝试表示此关系时出现尴尬的自连接查询。如果孩子有两个父母，这本身就会变得很奇怪。所以对我来说，你会有很多不同的表格：

parent
child
child_to_parent (many-to-many join table)
school
child_to_school (one school to many children)
classes
child_to_classes (many-to-many)
classes_exams (one-to-many table relating exams to classes)
child_to_classes_exams (many-to-many table relating children to exams for specific classes)
* and maybe things like the following
teacher
teacher_to_classes (many-to-many)

现在肯定在你的课堂设计中（如果你正在使用OOP），你可以从一个普通的“人”类扩展子和父，这个类将处理设置公共属性的逻辑。