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

Question

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

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

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

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

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

模型#1

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

优点:简单，没有额外的表，没有连接，可能是最快的选择，并且从长远来看可能更少的数据库空间(4 字节 type_id)。并且 widgets 表 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 之外，没有标记/占位符值。无需预留预置值空间， future 预置类型添加无限制。

缺点:对于 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 表中引用。

优点:可能是最规范化的模型。从不使用空值或 FK 空值。没有使用 sentinal/placehodler 值。

缺点:在数据库中添加 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张表、accounts、widgets、types和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将为您提供共享主键技术的更详细描述。