数据库表中的循环引用

Question

我很难为情地问这个问题，但最近出现了一种情况，我需要为三种相互关联的不同类型的银行实体创建一个表。让我解释一下。

设想一个银行表，其中包含管理银行、运营农村分行的常规银行或在此银行或零售银行下运营的农村分行的详细信息，这些分行不属于此层次结构，但仅与农村分行进行交易。

以前，我决定为这些有4个不同的表，有FK约束(即管理银行，经营农村分行的银行，农村分行和零售银行分行各一个)。但当我继续创建交易表时，我感到困惑，因为交易可能发生在这些实体之间(例如:农村分支机构与零售分支机构之间，农村分支机构之间等等)。这意味着我不仅要记录银行实体的"Source“和”Destination“ID，还要保留一些数据来帮助应用程序逻辑确定连接哪个表进行查询，我觉得这很糟糕。

此外，有一个用户表，用户可以属于这些实体中的任何一个，这里也有4个不同的银行实体表是有问题的。我如何知道用户属于农村分行、零售分行还是管理银行？

因此，我创建了一个单一的银行表(本质上是因为它们是相似的实体，因为它们可以相互交易)。我在表中添加了一个PARENT列，该列将保存父机构的ID的值(使用FKs实现的关系)。因此，农村分行在其上级列中将具有经营银行的ID。零售分支没有父级，因此那里的值为空，以此类推。

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

我的问题是:这有多糟糕？有什么办法可以解决呢？

Answer 1

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

有关使用Common Table Expressions.

• See relationships.

执行分层查询的详细信息，请参阅

• 中的this article，其中详细介绍了在自引用中使用的一些查询

此外，我建议您使用此Bank表，但保留银行类型的辅助表，以便每个银行在bank表中都有一条记录，另外在其他表中也有一条记录，其中包含特定于银行类型的扩展属性。这样，关系仍然是集中的，用户仍然可以使用单个FK绑定到Bank表，但是您的Bank表不会被所有不同银行类型的扩展属性搞混。