数据库表中的循环引用

Question

我很惭愧地问这个问题，但最近出现了一种情况，那就是我需要为三种不同类型的银行实体创建单个表格，这三种不同类型的银行实体彼此相关。让我解释。

想象一张银行表格，其中包含一个管理银行或经营农村分行的正常银行的详细信息，或者在本行或零售银行分行下经营的农村分行，这些分行不属于此分层结构，但仅与农村分支。

此前，我决定为这些人制定4个不同的表格，这些表格受到FK限制（即指导行，农业分行，农村分行和零售银行分行）。但是，当我开始创建TRANSACTION表时，我感到困惑，因为任何这些实体之间可能发生交易（例如：农村分行&零售分行，农村分行之间等）。这意味着我不仅要记录银行实体的“目的地”ID，还要保留一些数据以帮助应用程序逻辑确定要加入哪个TABLE进行查询。我觉得这是不好的

此外，还有一个USER表，用户可能属于这些实体中的任何一个，这里也有4个不同的银行实体表存在问题。我怎么知道用户是属于农村分支还是零售分支机构还是执行银行？

因此，我创建了一个单一的BANK表（实质上是因为它们是相似的实体，因为它们可以相互处理）我在表中添加了一个PARENT列来保存ID的值母机构的关系（关系I ot herwise使用FKs实现）。因此，农村分行的母行栏中会有操作银行的ID。零售分行没有父母，因此其值为NULL等等。

我现在看到的问题是，在BANK表中有一个PK/FK关系，这是一个循环引用。

我的问题是：这有多糟糕？什么可能是一个出路？

Answer 1

有自我指涉关系并不少见。一个缺点是，许多RDBMS不允许您对自我参照关系执行级联删除。除此之外，这种等级关系没有任何巨大的缺陷。许多数据库解决方案甚至支持扩展功能来促进这种类型的关系。

• 请参阅this article关于使用Common Table Expressions执行分层查询。
• 查看this MySQL article详细说明了一些在自我参照关系中使用的查询。

此外，我可能会建议你有这样的银行表，但保留对银行类次表，使得每家银行必须在银行表中的记录，另外将有一个纪录的一个其他表格持有银行类型特定的扩展属性。这样的话，关系仍然是集中的，用户仍然可以使用单个FK绑定到银行表格，但是您的银行表格不会与所有不同银行类型的扩展属性混淆。