同一张表的八个外键答案

【问题标题】：Eight foreign keys to the same table同一张表的八个外键
【发布时间】：2012-09-17 14:46:33
【问题描述】：

也许，我快疯了，最后我忘记了我学到的一切，但我对我正在设计的数据库模型有很多疑问。

这是我的问题：

我有一个包含 n 列的表，其中八列将有三个可能的值：YES、NO、UNKNOWN。

我认为我可以使用另一个带有 PK 和描述的表，但我不确定我是否可以创建从一个表到同一个表的八个外键。

我的问题是：

我是否需要第二张表来存储 YES、NO 和 UNKNOWN？同一张表可以有八个外键吗？

【问题讨论】：

当然有可能，不过你考虑过 ENUM 吗？
您的数据库可能有所不同？我注意到你关于数据库的抽象问题都没有提到你正在使用什么数据库。这可能是相关的。（MySQL 和 postgreql 都有 ENUM。）
这是针对 SQL Server 2008 和针对 Android 的 Sql lite 的数据库设计。我将在软件方面使用 Enum，或者我可能会将 YES、NO 和 UNKNOWN 存储为文本。
例如 MySQL 为列提供了 ENUM 和 SET 类型。

【解决方案1】：

你没疯。

有一种方法可以对数据进行建模，最终得到用作集线器的表，许多其他表通过 FK/PK 机制引用这些集线器。该设计称为“星型模式”。充当中心的表称为“事实表”。引用它们的表称为“维表”。还有另一种称为“雪花模式”的设计，其中维度表本身被其他表引用。

您不能设计既是星型又是规范化的模式。它们是两个不同的学科，每个学科都有其最佳适用领域。星型模式适用于数据仓库、数据集市和报告数据库。结果证明，生成复杂的分析查询非常容易。更新星型模式是一件非常痛苦的事情。因此，在您进行 OLTP 时，规范化设计效果更好。

星型模式最初是作为一种将所谓的“多维建模”转移到 SQL 数据库领域的方式而开发的。多维建模用于来自 Cognos 和其他公司的数据立方体等结构。

但是，星型架构的设计目标与您在问题中概述的目标非常不同。

【讨论】：

【解决方案2】：

我是否需要第二张表来存储 YES、NO 和 UNKNOWN？

不是真的。为什么不直接使用 DBMS 提供的“bool”（或“bit”等）类型，其值为 TRUE（或 1 或其他）、FALSE（或 0）和 NULL？

或者，考虑一个简单的 INT，其中每个值都记录在案并为所有客户“熟知”。如果 DBMS 支持它（MySQL），则为 ENUM。请不要将字符串用于逻辑上的布尔值或枚举 - 您最终会在许多重复的字符串上浪费空间。

只有在以下情况下，我才会考虑单独的表格：

同一张表可以有八个外键吗？

同一个表可能是八个外键的父端点。同一个表也有可能（尽管 smelly）是八个 FK 的子端点。

所以是的，这是可能的。

【讨论】：

【解决方案3】：

毫无疑问，在一个设计中可能有八个外键（但可能有一些 RDBMS 不允许这样做），但我确实想知道如果你认为这是在建模哪个问题域解决方案。

外键描述了一种关系，其中具有外键的表将包含依赖于引用表中记录的记录。有八个引用来跟踪两个表中记录之间的一对一关系似乎有点奇怪。

特别是因为列只能包含三个值。那将表达哪种关系？被引用的表可以指示多少条记录？

如果没有更多细节，我会说你的设计被破坏了。

【讨论】：

【解决方案4】：

按照您的描述，拥有外键是完全可以的。尝试一下。

ENUM 当然也可以，只要您永远不会有更多状态需要处理（例如“可能”），或者需要移动到可能不支持枚举的不同数据库。

【讨论】：

嗯，只是为了把它放在一个更合理的基础上。涉及大量引用一些值的模式是“享元模式”，它是完全合法的，甚至受到鼓励。这是强大设计的证据。我会将其标记为高于使用枚举或编码值。它增强了数据完整性并且是完全标准的（与枚举不同）。它的风险也较小，因为它可以适应变化。因此，从纯粹的数据设计的角度来看，它是更可取的解决方案，尽管看起来很奇怪。