也许，我快疯了，最后我忘记了我学到的一切，但我对我正在设计的数据库模型有很多疑问。
这是我的问题：
我有一个包含 n 列的表，其中八列将具有三个可能的值：YES、NO、UNKNOWN。
我认为我可以使用另一个带有 PK 和描述的表，但我不确定我是否可以创建从一个表到同一个表的八个外键。
我的问题是：
我是否需要第二张表来存储 YES、NO 和 UNKNOWN？同一张表可以有八个外键吗？
问问题
126 次
4 回答
1
我是否需要第二张表来存储 YES、NO 和 UNKNOWN？
并不真地。为什么不直接使用 DBMS 提供的“bool”（或“bit”等）类型，其值为 TRUE（或 1 或其他）、FALSE（或 0）和 NULL？
或者，考虑一个简单的 INT，其中每个值都被记录并为所有客户“熟知”。如果 DBMS 支持它（MySQL），则为 ENUM。请不要将字符串用于逻辑上的布尔值或枚举 - 您最终会在许多重复的字符串上浪费空间。
只有在以下情况下，我才会考虑单独的表格：
- 值需要是动态的（即用户可以添加新值）
- 或者您需要为每个值提供附加信息（例如描述或评论）。
同一张表可以有八个外键吗？
同一个表可能是八个外键的父端点。同一张表也有可能（虽然很臭）是八个 FK 的子端点。
所以是的，这是可能的。
于 2012-09-17T16:15:25.093 回答
1
你没疯。
有一种数据建模方法，最终以表作为集线器，许多其他表通过 FK/PK 机制引用这些集线器。该设计称为“星型模式”。充当中心的表称为“事实表”。引用它们的表称为“维表”。还有另一种称为“雪花模式”的设计，其中维度表本身被其他表引用。
您不能设计既是星型又是规范化的模式。它们是两个不同的学科，每个学科都有其最佳适用领域。星型模式适用于数据仓库、数据集市和报告数据库。结果证明，生成复杂的分析查询非常容易。更新星型模式是一件非常痛苦的事情。出于这个原因，当您进行 OLTP 时，规范化设计效果更好。
星型模式最初是作为一种将所谓的“多维建模”转移到 SQL 数据库领域的方式而开发的。多维建模用于 Cognos 等数据立方体等结构中。
但是，星型模式的设计目标与您在问题中概述的目标非常不同。
于 2012-09-18T11:18:35.547 回答
0
毫无疑问，一个设计中可能有八个外键（但可能有一些 RDBMS 不允许这样做），但如果您将其视为解决方案，我确实想知道您正在建模哪个问题域。
外键描述了一种关系，其中具有外键的表将包含依赖于引用表中记录的记录。有八个引用来跟踪两个表中记录之间的一对一关系似乎有点奇怪。
特别是因为列只能有三个值。那将表达哪种关系？引用表中可以表示多少条记录？
如果没有更多细节，我会说您的设计已损坏。
于 2012-09-17T14:54:02.680 回答
0
正如您所描述的，拥有外键是完全可以的。尝试一下。
当然，ENUM 也很好，只要您永远不会有更多的状态需要处理（例如“可能”），或者需要移动到可能不支持枚举的不同数据库。
于 2012-09-19T13:04:38.667 回答