我很惭愧地问这个问题，但最近有一种情况我需要为三种不同类型的银行实体创建一个表，这些银行实体彼此相关。让我解释一下。
想象一下BANK表，其中包含管理银行或经营农村分支机构的常规银行，或在本行或零售银行分支机构运营的农村分支机构的详细信息，这些分支机构不属于此等级但仅与农村地区进行交易科。
之前，我决定为这些提供4个不同的表格，有FK约束（即Governing Bank，运营农村分行的银行，农村分行和零售银行分行各一个）。但是当我继续创建TRANSACTION表时，我感到困惑，因为交易可能发生在任何这些实体之间（例如：农村分支和零售分支之间，农村分支机构之间等）。这意味着我不仅要记录“来源”和“银行实体的“目的地”ID，但也保留一些数据，以帮助应用程序逻辑确定要加入哪个TABLE进行查询。我觉得这很糟糕。
此外，有一个USER表，用户可以属于这些实体中的任何一个，这里也有4个不同的银行实体表是有问题的。我如何知道用户是属于农村分支机构还是零售分支机构还是管理银行？
因此，我创建了一个BANK表（主要是因为它们是相似的实体，因为它们可以相互交易）。我在表中添加了一个PARENT列，该列将保存父机构的ID值（否则我使用FK实现的关系）。因此，农村分支机构的父列中将包含操作银行的ID。零售分支没有父母，因此其值为NULL等等。
我现在看到的问题是BANK表中有一个PK / FK关系，一个循环引用。
我的问题是：这有多糟糕？什么可能出路呢？
答案 0 :(得分：3)
拥有自我参照关系并不罕见。一个缺点是许多RDBMS不允许您对自引用关系执行级联删除。除此之外，这种等级关系没有任何巨大的陷阱。许多数据库解决方案甚至支持扩展功能以促进这种类型的关系。
此外，我是否可以建议您拥有此银行表，但保留银行类型的辅助表，以便每个银行在银行表中都有一个记录，另外还有其他一个表中的记录银行类型特定的扩展属性。这样，关系仍然是集中的，用户仍然可以使用单个FK绑定到Bank表，但是您的Bank表格不会被所有不同银行类型的扩展属性混淆。