关于可空外键和规范化的数据库设计问题

Question

我希望就哪种数据库模式最适合我的情况达成共识，以便在表中存储小部件的“类型”信息。 Widget 只能有一种类型，但该类型可以是 Preset-Type 或 Custom-Type。我显然会创建预设类型，而用户会创建自定义类型。

我将在服务器上使用 MySQL 和 INNODB。我还将使用 SQLite 在应用程序上存储相同的信息。但是我们在这里只讨论服务器。我是一名应用程序员，而不是数据库管理员，但我想在第一时间就为这个项目找到正确的数据库并在合理范围内进行规范化。

在搜索是否应该对外键使用空值时，我从比我拥有更多数据库经验的人那里得到了以下答案。

• “当然，Null 可以在外键和其他地方使用。”
• “外键中的 NULL 完全可以接受。”
• “NULL 必不可少的一个领域是外键。”
• “几乎不应该使用 Null，尤其是在外键中。”
• “绝不能在任何地方使用 Null。”
• “具有大量 NULL 值的列通常表明需要（进一步）规范化。”

我需要知道在模型 #2 的特定情况下使用 Null 是否是不好的做法，以及哪种模型更可取以及为什么。或者可能建议一个更好的模型。感谢您的任何意见。

型号 #1

对于预设和自定义类型都有一个“类型”表。我通过使用预设类型预先填充“类型”表并为以后可以添加的未来预设类型保留大约 1500 个保留空间来做到这一点。

优点：简单，没有额外的表，没有连接，可能是最快的选择，并且从长远来看可能更少的数据库空间（4 字节 type_id）。并且小部件表 type_id FK 永远不会为 NULL。

缺点：将预设和自定义类型混合在一起可能不是很好的规范化做法，因为预设不需要“account_id”等字段。如果我想要超过 1500 个预设（极不可能），我需要弄清楚别的东西出来。此模型还使用类型表中的标记/占位符值作为预设和保留的预设点。

CREATE TABLE accounts (
    account_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    # Other Columns...,
    PRIMARY KEY (account_id)
    );  
CREATE TABLE widgets (
    widget_id   INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id  INT UNSIGNED NOT NULL, 
    type_id     INT UNSIGNED NOT NULL,
    PRIMARY KEY (widget_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id) ON DELETE CASCADE,
    FOREIGN KEY (type_id) REFERENCES types(type_id)
    );  
CREATE TABLE types (
    type_id     INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id  INT UNSIGNED NOT NULL, 
    name        VARCHAR(100) NOT NULL,
    PRIMARY KEY (type_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id)
    );

型号 #2

预设和自定义类型的单独小部件类型表。 'widgets' 表具有预设类型和自定义类型的可为空的 FK 字段。 Check 约束确保其中一个为空，另一个不为空。

优点：数据库中只有 1 个额外的表。除了可能为空的 FK 之外，没有任何标记/占位符值。无需预留预置值空间，对未来预置类型添加无限制。

缺点：对于preset_type_id 或custom_type_id，widgets 表中的每条记录使用一个FK null。

CREATE TABLE accounts (
    account_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    # Other Columns...,
    PRIMARY KEY (account_id)
    );  
CREATE TABLE widgets (
    widget_id       INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id      INT UNSIGNED NOT NULL, 
    preset_type_id  INT UNSIGNED DEFAULT NULL,
    custom_type_id  INT UNSIGNED DEFAULT NULL,
    PRIMARY KEY (widget_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id) ON DELETE CASCADE,
    FOREIGN KEY (preset_type_id) REFERENCES preset_types(preset_type_id),
    FOREIGN KEY (custom_type_id) REFERENCES custom_types(custom_type_id),
    CHECK ((preset_type_id IS NOT NULL AND custom_type_id IS NULL) OR (preset_type_id IS NULL AND custom_type_id IS NOT NULL) )
    );  
CREATE TABLE preset_types (
    preset_type_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    name            VARCHAR(100) NOT NULL,
    PRIMARY KEY (preset_type_id)
    );  
CREATE TABLE custom_types (
    custom_type_id  INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id      INT UNSIGNED NOT NULL, 
    name            VARCHAR(100) NOT NULL,
    PRIMARY KEY (custom_type_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id)
    );

模型#3

使用中间表 widget_preset_types 和 widget_custom_types。如果小部件具有预设类型，它将在 widget_preset_types 表中引用，或者如果小部件具有自定义类型，它将在 widget_custom_types 表中引用。

优点：可能是最标准化的模型。永远不要使用 Null 或 FK Null。没有使用哨兵/占位符值。

缺点：在数据库中添加 3 个额外的表只是为了确定小部件类型。除了具有自定义/预设类型的数据库中的小部件之外，我还有其他东西，这意味着我可以使用此模型向我的数据库中添加至少 12 个额外的表。是否过度标准化？我将不得不使用某种类型的连接来同时从 3 个表中获取所有小部件信息和类型信息。我将不得不检查 custom_type_id 或 preset_type_id 是否在连接中返回，可能使用的代码比我在 Model#2 中检查空值时使用的代码多。可能比模型 1 和 2 慢。更多的表意味着更多的索引意味着更多的内存。

CREATE TABLE accounts (
    account_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    # Other Columns...,
    PRIMARY KEY (account_id)
    );  
CREATE TABLE widgets (
    widget_id       INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id      INT UNSIGNED NOT NULL
    PRIMARY KEY (widget_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id) ON DELETE CASCADE
    );
CREATE TABLE preset_types (
    preset_type_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    name            VARCHAR(100) NOT NULL,
    PRIMARY KEY (preset_type_id)
    );  
CREATE TABLE custom_types (
    custom_type_id  INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id      INT UNSIGNED NOT NULL, 
    name            VARCHAR(100) NOT NULL,
    PRIMARY KEY (custom_type_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id) ON DELETE CASCADE
    );
CREATE TABLE widget_preset_types (
    widget_id       INT UNSIGNED NOT NULL UNIQUE, 
    preset_type_id  INT UNSIGNED NOT NULL, 
    PRIMARY KEY (widget_id),
    FOREIGN KEY (widget_id) REFERENCES widgets(widget_id) ON DELETE CASCADE,
    FOREIGN KEY (preset_type_id) REFERENCES preset_types(preset_type_id)
    );  
CREATE TABLE widget_custom_types (
    widget_id       INT UNSIGNED NOT NULL UNIQUE, 
    custom_type_id  INT UNSIGNED NOT NULL,
    PRIMARY KEY (widget_id),
    FOREIGN KEY (widget_id) REFERENCES widgets(widget_id) ON DELETE CASCADE,
    FOREIGN KEY (custom_type_id) REFERENCES custom_types(custom_type_id)
    );

Answer 1

一些非常优秀的设计人员在外键中使用 NULL 不会产生不良后果。我自己就是这样倾斜的。可为空的 FK 表示可选关系。在实体没有关系的情况下，FK 包含 NULL。空间开销是最小的。当跨两个表进行连接（更准确地说是等连接）时，FK 中包含 NULL 的实例将退出连接，这是适当的。

话虽如此，我将向您推荐第四种方法。这涉及到总共 4 个表、帐户、小部件、类型和 custom_types。 custom_types 表使用一种称为 Shared-primary-key 的技术，如下所述。

CREATE TABLE accounts (
    account_id  INT UNSIGNED AUTO_INCREMENT NOT NULL, 
    # Other Columns...,
    PRIMARY KEY (account_id)
    );  
CREATE TABLE widgets (
    widget_id   INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id  INT UNSIGNED NOT NULL, 
    type_id     INT UNSIGNED NOT NULL,
    PRIMARY KEY (widget_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id) ON DELETE CASCADE,
    FOREIGN KEY (type_id) REFERENCES types(type_id)
    );  
CREATE TABLE types (
    type_id     INT UNSIGNED AUTO_INCREMENT NOT NULL,
    account_id  INT UNSIGNED NOT NULL, 
    name        VARCHAR(100) NOT NULL,
    PRIMARY KEY (type_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id)
CREATE TABLE custom_types (
    type_id     INT NOT NULL,
    account_id  INT UNSIGNED NOT NULL, 
    PRIMARY KEY (type_id),
    FOREIGN KEY (type_id) REFERENCES types(type_id),
    FOREIGN KEY (account_id) REFERENCES accounts(account_id)

);

custom_types 中的 type_id 列是共享主键。请注意，它被声明为主键和外键，并且它不使用自动编号。它是相应条目的类型中主键的副本。自定义类型表包含自定义类型中存在但预设类型中不存在的所有数据。

对于预设类型，在 types 中创建条目，但在 custom_types 中没有条目。对于 custom_types，首先在 types 中创建一个条目，然后 type_id 的结果值与 account_id 一起复制到 custom_types。

如果您使用 INNER JOIN 类型和 custom_types，预设类型会退出连接。如果您希望在单个联接中同时使用自定义类型和预设类型，则必须使用 LEFT JOIN 或 RIGHT JOIN 才能获得该效果。请注意，LEFT 或 RIGHT JOIN 的结果将包含一些 NULL，即使这些 NULL 未存储在数据库中。

单击此shared-primary-key 将为您提供有关共享主键技术的更详细说明。

Answer 2

第一次为这个项目获得正确的数据库

这几乎是不可能的。最好计划在项目几个月后修改架构。

Null vs FK

首先，确定哪些列需要带外“空”值。只有这样才能确定 FK 是否可用，或者是否比它的价值更麻烦。

大多数列将始终存在，因此NOT NULL。但有些可以是NULL：

• 一个未知的值。示例：end_date
• 一个可选值。
• （还有更多）

归一化

没有规范化通常不好；
过度标准化也通常不好；
除非您对会有多少小部件、它们的名称有多少不同等有所了解，否则很难找到中间立场。

规范化可能有两个原因：

• 数据完整性（有点）。将经常出现的事物（通常是某物或某人的“名称”）移动到一个地方，从而在需要时可以轻松高效地更改名称。这在上沃尔特更名为布基纳法索时有所帮助，但对南斯拉夫的分裂毫无用处。
• 性能。如果一个长名称出现在几十个地方和大量索引中，则会占用磁盘空间、I/O 时间，在较小程度上还占用 CPU 时间。

对于一千个“事物”，标准化并不重要。
对于十亿“事物”，标准化至关重要。
同样，在第一天调整中间立场可能是不可能的。

预设与自定义类型

您将它们呈现为几乎相同。但是随后您继续建议“预设”类型缺少某些属性。 （“缺失”==“空”？？）

将“类型”视为实体。并且您的其他表与它有关系。可能是多对多。

不要“保留 1500”。如果您需要区分预设与自定义，请添加一列说明哪个是哪个。预订最终会给你带来麻烦。

type.account_id（在第一个模式中）的存在意味着多个帐户不使用“类型”。然而预设类型可以吗？啊!不赞成模型 1。

用于重置和自定义的单独列。这有点像“一个小部件可以各有一个”。不赞成 Model 2。

Model 3 有多个表，在小部件和每种类型的 type 之间有“多对多”映射的味道。你真的想要多对多吗？

4 字节 type_id

当然，INT 是 4 个字节。但是你真的期待十亿或更多的“类型”吗？使用较小的数据类型。例如，MEDIUMINT UNSIGNED 是 3 个字节，溢出了 1600 万个字节。 （等）

重新开始……

您有 3(?) 个实体：小部件、帐户、类型。每个人都需要一张桌子。 （或至少一个主表——例如：一个order 由许多order_items 组成。）

这些实体具有 1:1 或 1:many 或 many:many 关系。决定哪个适用于哪里。

• 1:1 通常是“错误的”，因此请尽量避免。
• 1:many 有一个 id 表示“1”在“many”表中。
• many:many 需要一个带有一对 id 的额外表。

3 个实体表，加上任何多：多关系表，构成了架构的核心。 （同时，我看不到“规范化”在您的小架构中的位置。）

然后在需要的地方添加FOREIGN KEYs。 （FK 不是强制性的。）

换句话说，当您问“一个问题是“我需要知道使用 Null 是否是不好的做法”时，我认为您是“本末倒置”。