避免循环依赖

Question

我正在开发一个旅行管理应用程序。有问题的设计如下所示：

旅行中的每个人都被指定为旅行者。 每个旅行者都有一本护照。 现在，Traveler 可以是 MainMember 或 SubMember，这取决于他是否是一家之主。 MainMember 决定诸如 TourPackage 之类的东西，他的旅行家庭的总金额等。 SubMember 在旅行时依赖于 MainMember。因此，如果 MainMember 被删除，它的所有 SubMember 也必须被删除。

所以， 旅行者有护照。 （一对一关系） Traveler 是 MainMember 或 SubMember。 （Traveler-MainMember 和 Traveler-SubMember 之间的一对零/一对） 一个 MainMember 可能有多个 SubMember。 （一对多） 一个 SubMember 只有一个 MainMember。 （多对一）

我目前的 ERD 如下所示。

如您所见，三个表 - Traveler、MainMember 和 SubMember - 形成了循环依赖关系。不过，我不确定这是否会损害我的申请。 如果我删除了一个作为 MainMember 的 Traveler，那么 1. Traveler中的一条记录被删除。 2、删除其相关的MainMember记录。 3、删除依赖于MainMember的SubMember记录。 4. 删除子会员的旅行者记录。

虽然这似乎不是问题，但作为 Traveler-MainMember 删除将始终只删除 Traveler-SubMember。不过，我对此有一种不好的预感。

谁能指导我做出更好的设计？

更新 -

在等待回复时，我根据@Daveo 的回复想出了另一个设计。基本上，Traveler 包含自引用外键。 SubMember 记录将使用它来识别他们的父母。

这是 ERD。

现在，正如@Branko 所指出的，我之前的设计中没有循环依赖的问题，我想知道哪种设计更好？

另外，哪种设计更适合通过 Hibernate 实现？我认为第二种方法在通过 Hibernate 实现时可能会导致复杂性。

对于您喜欢的设计，我还希望能提供一些关于实现模式（Hibernate 实体中的继承等）的建议。

Answer 1

如您所见，三个表 - Traveler、MainMember 和 SubMember - 形成了循环依赖关系。

不，这不是循环依赖 - 此图中的任何“节点”都无法通过沿着正确方向的图“边”到达自身¹。它可以更准确地描述为“合并”甚至（原型）“菱形”依赖。

不，它不会损害您的应用程序。²

您正在使用“单独表中的每个类”方法有效地实现继承（又名类别、子类化、子类型化、泛化层次结构等）。这种方法是干净的，但不能保证开箱即用的存在性³ 和排他性⁴。 amend it 有一些方法可以做到，还有其他的继承实现策略可以，但它们有自己的pros and cons。

在我看来，您的模型非常适合您尝试完成的任务，并且在应用程序级别执行存在/排他性可能比尝试在数据库级别执行它的弊端要小。

---

¹ “方向”是从引用到引用的表。 Traveller 既不引用 MainMember 也不引用 SubMember，因此打破了循环。

² 除非您使用的 DBMS（例如 MS SQL Server）不支持对此类“合并”依赖项的引用操作（在这种情况下，您需要实现ON CASCADE DELETE 通过触发器）。

³Traveller不能单独存在（不能是“抽象”），必须是MainMember或SubMember。

⁴Traveller 不能同时是 MainMember 和 SubMember。

Answer 2

我将在数据库中只有两个表。

旅行者和密码

Traveller 将有一个 Parent_Id 字段，该字段将链接回 Traveler 表并存储主要/主要旅行者是谁。 还存储此表中主/子成员共有的字段，如联系号码

然后使用继承和 ORM 在您的实际应用程序中创建两个不同的类。 主成员和子成员 MainMember 将是 Traveler 中 Parent_Id 为空的所有行 SubMember 将是 Traveler 中 Parent_Id 不为空的所有行