DB Design：什么时候应该创建一个公共属性的超类？

Question

为了描述我的困境，让我首先从一个示例问题开始（从here 窃取）。假设您的数据库中有一个 GradStudent 表，如下所示：

GradStudent:
firstName
lastName
birthDate
courseAssignment
researchGrant

但只有助教才有课程作业，只有研究助理才有研究资助，所以这两者中的一个将始终为空。显然这不是最优的，最好这样做：

GradStudent:
firstName
lastName
birthDate

TeachAsst:
courseAssignment

ResearchAsst:
researchGrant

TeachAsst 和 ResearchAsst 有一个来自 GradStudent 表的外键（可能是“studentID”代理）。

我也理解为什么最好不要制作两个完全独立的表格，例如：

TeachAsst:
firstName
lastName
birthDate
courseAssignment

ResearchAsst:
firstName
lastName
birthDate
researchGrant

因为你重复了很多具有相同含义的属性。

但是，如果两个不同的类会有意义（我认为）如果它们几乎没有任何共同的领域，例如：

TeachAsst:
name
courseAssignment
payRate
numStudents

ResearchAsst:
name
researchGrant
facultyAdvisor
researchTopic

在这里，它们只有一个共同的“name”，所以让一个 GradStudent 超类只有一个“name”属性会很愚蠢吗？转折点在哪里？您如何决定何时拥有公共信息的超类，或者何时让两个类完全分开？拥有超类会使大部分 CRUD 变得更加困难，因为要创建或更新 TeachAsst，您需要更改两个表，而不仅仅是一个。

再举一个例子，假设您正在处理的数据库涉及测量不同电子设备上的信息。虽然相机和手机有相同的长度/宽度/高度，但大多数其他测量值不会重合（例如，相机不会有任何音频信息，手机不会有任何镜头或视口测量值）。因此，拥有一个完全独立的 cameraData 表和一个 mobileData 似乎几乎更简单，而不是将它们的少量公共信息放入一个超类表中。你怎么看？是否有一般规则规定您应该始终将公共数据放在一个超类中，即使它只是子类的描述性数据的一小部分？

编辑：假设在研究生示例中，研究生要么是助教，要么是研究助理，永远不会转换角色，也永远不会两者兼而有之。

Answer 1

在 GradStudent 场景中，您具有以下属性：

GradStudent 可以先成为 TeachAsst，然后再成为 ResearchAsst。或者她可以同时是两者。

在这种情况下，非规范化可能不是一个好主意。

但在您的情况下，您测量的是相机和手机。他们永远不会变成别的东西。为了降低复杂性，我认为你可以冒险去规范化。

或者，您甚至可以考虑使用像 CouchDB 这样的文档数据库，您不必遵循任何架构。

Answer 2

我认为自己对数据库设计相对较新，因此值得一试。在第一个示例中，我的第一个想法是确实维护一个单独的“GradStudent”表，其中包含姓名和其他个人信息。在我看来，它可以让你灵活应对未来的潜在变化。例如，如果创建了除 TeachAsst 或 ResearchAsst 之外可由个人担任的另一个 GradStudent 角色怎么办？您可以创建一个“GradStudent_Relationship”表，以便将来容纳更多角色：

GradStudent_Relationship:
GradStudent_ID (fk)
ResearchAsst_ID (fk)
TeachAsst_ID (fk)
NewGradStudentRole_ID (fk)

至于让您的 CRUD 操作更加困难，在我看来，增加的灵活性胜过这种担忧。也许您可以在数据库中设置触发器来帮助解决这个问题？

关于第二个例子，为什么相机不能有音频？某些数码相机不会录制包含音频的视频吗？另外，为什么手机不能有镜头或视口测量？现在不是很多手机都带摄像头了吗？

对于它的价值，我有时会发现尽我所能抽象“类”以保持最大的灵活性是有帮助的。正如您所提到的，在 CRUD 操作方面可能存在一些折衷，但就我个人而言，我喜欢知道数据库架构可以处理未来的潜在变化。

我希望这至少有点帮助。