由于以下几个原因,循环引用可能不好:
- 在必须存在关系的情况下(即,从业务和技术需求的角度来看,老师必须有班级,班级必须有老师),您会遇到先有鸡还是先有蛋的场景:您可以不能无班加老师,也不能无班加班。
- 很难弄清楚层次结构的“顶部”是什么(因为,说实话,没有“顶部”)
假设您可以有没有课程的老师和/或没有课程的科目,听起来这两者中的一个将是“顶级”(从商业角度来看,我假设它将是科目)。
如果您所拥有的工作正常,我看不出设计有问题,也看不到设计它的替代方法。
评论后编辑
单向依赖没有问题(这就是普通的不可为空的外键)。
根据您的评论,我觉得我也应该指出一些事情:对循环依赖的反对是技术性的,而不是逻辑性的。如果企业说没有课就没有老师,没有老师就没有课,那很好;您只是无法以这种方式对数据进行建模,否则您将永远无法添加任何内容。您必须定义哪些对象——班级或教师——被允许独立存在(从技术角度来看,而不是从业务角度来看)。
教师和班级之间存在 M:M 关系这一事实使您有些幸免,因为这迫使您使两者都能够独立存在(因为连接是在链接表中建立的,而不是在参与者表中建立的)他们自己。
因此,您没有真正的循环依赖。您的业务逻辑是循环的,但这很好,因为您可以完全控制它的运行方式。您的布局看起来像这样:
Teacher <----- TeacherClass -----> Class
^ ^
| |
| |
TeacherSubject --------------------> Subject
(如果一个老师可以有多个科目)
或这个:
Teacher <----- TeacherClass -----> Class
| ^
| |
| |
\----------------------------> Subject
(如果一个老师只能有一个科目)
或这个:
Teacher <----- TeacherClass -----> Class
^ ^
| |
| |
\----------------------------- Subject
(如果一个科目只能有一位老师)
在第一种情况下,两者Teacher
都是Class
顶级实体,因为它们都不指向其他任何东西(链接表完成了这一点)。在第二个中,onlyClass
是一个顶级实体。
只要路径上的某个地方有一个顶级实体,就可以了。首先,您可以按以下顺序添加记录:
Teacher -> Class -> (TeacherClass -> Subject) -> TeacherSubject
(我TeacherClass -> Subject
用括号括起来,因为你可以按任何顺序添加它们)
在第二个中,您可以按以下顺序添加它们:
Class -> Subject -> Teacher -> TeacherClass
第三,您可以按以下顺序添加它们:
Class -> Teacher -> (TeacherClass -> Subject)
因此,从技术角度来看,您没有真正的循环依赖。