2

为了描述我的困境，让我首先从一个示例问题开始（从这里偷来的）。假设您的数据库中有一个 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 似乎几乎更简单，而不是将它们的少量公共信息放入一个超类表中。你怎么看？是否有一条一般规则说您应该始终将公共数据放在一个超类中，即使它只是子类描述性数据的一小部分？

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

4

2 回答 2

1

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

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

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

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

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

我希望这至少有点帮助。

于 2009-06-17T15:55:57.697 回答
0

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

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

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

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

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

于 2009-06-17T14:04:28.653 回答