代码之家  ›  专栏  ›  技术社区  ›  JoeCool

DB设计:什么时候应该创建公共属性的超类?

  •  2
  • JoeCool  · 技术社区  · 15 年前

    为了描述我的困境,让我首先从一个例子问题(从 here )。假设数据库中有一个Gradstuent表,如下所示:

    GradStudent:
    firstName
    lastName
    birthDate
    courseAssignment
    researchGrant
    

    GradStudent:
    firstName
    lastName
    birthDate
    
    TeachAsst:
    courseAssignment
    
    ResearchAsst:
    researchGrant
    

    其中Teachast和ResearchAsst从GradustStudent表中有一个外键(可能是“studentID”代理项)。

    TeachAsst:
    firstName
    lastName
    birthDate
    courseAssignment
    
    ResearchAsst:
    firstName
    lastName
    birthDate
    researchGrant
    

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

    然而,有两个不同的类别 如果他们几乎没有任何共同领域,比如:

    TeachAsst:
    name
    courseAssignment
    payRate
    numStudents
    
    ResearchAsst:
    name
    researchGrant
    facultyAdvisor
    researchTopic
    

    另一个例子是,假设您正在使用的DB涉及测量不同电子设备上的信息。虽然相机和手机有相同的长度/宽度/高度,但大多数其他测量值不会一致(例如,相机不会有任何音频信息,手机也不会有任何镜头或视口测量值)。因此,将cameraData表和mobileData完全分开似乎比将它们的少量公共信息放入超类表更简单。你怎么认为?是否有一条一般规则规定,即使公共数据只占子类描述性数据的一小部分,也应始终将其放在一个超类中?

    2 回复  |  直到 15 年前
        1
  •  1
  •   Colin Brock    15 年前

    我认为我自己对数据库设计比较陌生,所以把它当作是值得的。在第一个例子中,我的第一个想法是维护一个单独的“GradStudent”表,其中包括姓名和其他个人信息。在我看来,它让你在未来的潜在变化中保持灵活性。例如,如果创建了另一个研究生角色,除了教师或研究助理之外,还可以由个人担任,该怎么办?您可以创建一个“Gradustudent_Relationship”表,该表可以容纳将来的其他角色,例如:

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

    至于让你的CRUD操作更加困难,在我看来,增加的灵活性超过了这一担忧。也许您可以在数据库中设置触发器来帮助实现这一点?

    关于第二个例子,为什么相机不能有音频?难道有些数码相机不录制包含音频的视频吗?还有,为什么手机不能有镜头或视口测量?现在不是很多手机都有摄像头吗?

    不管怎样,我有时发现尽可能地抽象“类”是很有帮助的,这样可以保持最大的灵活性。正如您所提到的,在CRUD操作方面可能存在一些折衷,但就我个人而言,我喜欢知道数据库模式可以处理将来可能发生的更改。

        2
  •  0
  •   Pierre Spring    15 年前

    在研究生场景中,您具有以下属性:

    研究生可以先当教师,然后再当研究助理。或者她可以同时是两个。

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

    CouchDB ,其中不必遵循任何模式。