2

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

想象一个 BANK 表,其中包含管理银行或经营农村分支机构的常规银行,或在该银行下运营的农村分支机构或不属于此层次结构但仅与农村分支机构进行交易的零售银行分行的详细信息。

以前,我决定为这些设置 4 个不同的表,具有 FK 约束(即管理银行、经营农村分行的银行、农村分行和零售银行分行各一个)。但是当我继续创建 TRANSACTION 表时,我感到很困惑,因为任何这些实体之间都可能发生交易(例如:农村分支机构与零售分支机构之间,农村分支机构之间等)。这意味着我不仅要记录银行实体的“源”和“目标”ID,还要保留一些数据来帮助应用程序逻辑确定要加入哪个表以进行查询。我觉得那是坏的。

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

因此,我创建了一个 BANK 表(主要是因为它们是相似的实体,因为它们可以相互交易)。我在表中添加了一个 PARENT 列,该列将保存父机构的 ID 值(我使用 FK 实现的关系)。因此,农村分行将在其父列中具有运营银行的 ID。零售分支机构没有父母,因此那里的值为 NULL 等等。

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

我的问题是:这有多糟糕?什么是出路?

4

1 回答 1

3

具有自我参照关系并不少见。一个缺点是许多 RDBMS 不允许您对自引用关系执行级联删除。除此之外,这种等级关系并没有什么大的陷阱。许多数据库解决方案甚至支持扩展功能以促进这种类型的关系。

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

于 2010-02-03T13:39:58.610 回答