Database design 同一个表的八个外键

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

这是我的问题：

我有一个包含n列的表，其中8列将有三个可能的值：是、否、未知

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

我的问题是:

---

我是否需要第二张桌子来存储是、否和未知？有可能在同一个表中有八个外键吗？

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

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

尤其是因为列只能有三个值。那会表达什么关系？引用表中可以显示多少条记录

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

我是否需要第二张桌子来存储是、否和未知

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

可选地，考虑一个简单的INT，其中每个值被记录并对所有客户端“众所周知”。或者一个枚举（如果DBMS支持的话）（MySQL）。请不要将字符串用于逻辑上属于布尔值或枚举的内容-您将在许多重复的字符串上浪费空间

<>我会考虑单独的表（如果）：

• 值需要是动态的（即用户可以添加新值）
• 或者，您需要为每个值提供附加信息（例如说明或注释）

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

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

所以是的，这是可能的。

你没有疯

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

您不能设计一个同时是星型和规范化的模式。它们是两个不同的学科，每个学科都有其最佳的适用范围。星型模式适用于数据仓库、数据集市和报告数据库。生成复杂的分析查询非常简单。更新星型模式是一项艰巨的任务。因此，在执行OLTP时，规范化设计工作得更好

星型模式最初是作为将所谓的“多维建模”转移到SQL数据库世界的一种方式开发的。多维建模用于Cognos和其他软件中的数据立方体等结构中

---

然而，星型模式的设计目标与您在问题中概述的目标大不相同。

使用您描述的外键完全可以。试试看

---

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

当然可以，尽管您考虑过ENUM吗？您的数据库可能会有所不同？我注意到，关于数据库的抽象问题中没有一个提到您正在使用的数据库。这可能是相关的。（MySQL和postgreql都有枚举）这是一个针对SQLServer2008和SQLLite的数据库设计。我将在软件端使用枚举，或者我可能会将YES、NO和UNKNOWN存储为文本。例如，MySQL同时提供枚举和列的SET类型。有人建议我使用Enum.Hmm，只是为了更合理一点。这种模式涉及到对一些价值观的大量引用，是“Flyweight模式”，它是完全合法的，甚至是受鼓励的。这是一个强大设计的证据。我会将其标记为高于枚举或编码值的使用。它增强了数据完整性，并且是完全标准的（与enum不同）。它的风险也较小，因为它可以适应变化。因此，从纯数据设计的角度来看，这是一个更好的解决方案，尽管看起来很奇怪。