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 回答