我很羞于问这个问题，但最近出现了一种情况，我需要为彼此相关的三种不同类型的银行实体创建一个表。让我解释一下。
想象一个 BANK 表，其中包含管理银行或经营农村分行的常规银行或该银行下经营的农村分行或不属于此层次结构但仅与农村地区进行交易的零售银行分行的详细信息分支。
之前，我决定为这些数据创建 4 个不同的表，并带有 FK 约束(即，管理银行、经营农村分行的银行、农村分行和零售银行分行各一个)。但是，当我继续创建 TRANSACTION 表时，我感到很困惑，因为交易可能发生在任何这些实体之间(例如:农村分支机构与零售分支机构之间、农村分支机构本身之间等)。这意味着我不仅必须保留银行实体的“源”和“目标”ID 的记录，还要保留一些数据来帮助应用程序逻辑确定要加入哪个表来进行查询。我觉得这是不好。
此外，还有一个 USER 表，用户可能属于这些实体中的任何一个，这里拥有 4 个不同的银行实体表也是有问题的。我如何知道用户是否属于农村分行、零售分行或管理银行？
因此，我创建了一个 BANK 表(本质上是因为它们是相似的实体，因为它们可以彼此进行交易)。我在表中添加了一个 PARENT 列，该列将保存父机构的 ID 值(我使用 FK 实现的关系)。因此，农村分行的父列中将包含运营银行的 ID。零售分支机构没有父级，因此该值为 NULL，依此类推。
我现在看到的问题是BANK表中存在PK/FK关系，循环引用。
我的问题是:这有多糟糕？出路是什么？
最佳答案
具有 self 参照关系并不罕见。一个缺点是许多 RDBMS 不允许您对自引用关系执行级联删除。除此之外，这种等级关系没有任何巨大的缺陷。许多数据库解决方案甚至支持扩展功能来促进这种类型的关系。
- 参见this article使用 Common Table Expressions 执行分层查询.
- 参见this MySQL article详细说明自引用关系中使用的一些查询。
此外，我是否建议您拥有此银行表，但保留银行类型的辅助表，以便每个银行在银行表中都有一条记录，并且另外在其他表之一中也有一条记录银行类型特定的扩展属性。这样，关系仍然是集中的，用户仍然可以使用单个 FK 绑定(bind)到银行表，但您的银行表不会与所有不同银行类型的扩展属性混淆。
关于database-design - 数据库表中的循环引用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2192111/