Database 是否需要主键？（6NF实施）

是5NF关系的6NF relvar表中所需的主键。考虑以下设置：

-- The 5NF table
CREATE TABLE party_address(
    address_id int NOT NULL,
    party_id int NOT NULL,
    -- some other columns
    PRIMARY KEY (address_id, party_id)
);

CREATE TABLE party_address_is_billing(
    address_id int NOT NULL,
    party_id int NOT NULL,
    value boolean NOT NULL,
    transaction_time tstzrange NOT NULL DEFAULT tstzrange(CURRENT_TIMESTAMP, NULL, '[)'),
    EXCLUDE USING GIST (address_id WITH =, party_id WITH =, transaction_time WITH &&)
);

是否需要在

参与方地址\u是账单

表上明确声明

主键

？由于排除约束指定了唯一标识符（

（地址id、参与方id、事务时间）

），因此显式指定

主键（地址id、参与方id、事务时间）

似乎是多余的。它还将创建一个额外的、不必要的索引

• 不在表上指定

  主键

  会产生什么后果

---

关系模型要求每个关系至少有一个键。它不需要您使用特定的关键字

在5NF表中，如果将密钥声明为

NOTNULL unique（address\u id，party\u id）

，则根本不会更改基础依赖项。从关系的角度来看，这就是您必须关注的问题——替代语法不会破坏底层的依赖关系。（这意味着关系模型与实现的“附加和不必要的索引”无关。）

因此，在“party\u address\u is\u billing”中，如果排除约束的行为像一个键约束，那么我认为就关系模型而言，您是正确的

不在表上指定主键的后果是什么

如果将主键约束替换为另一个行为相同的声明性约束，可能会让维护程序员感到惊讶。见文章

您还可以让框架程序员更加努力地工作。许多框架不仅需要主键约束，还要求约束是代理整数。（这实际上不是一个关系问题。）

一些软件工程（CASE）工具可能会因排除约束而阻塞

与违反排除约束的进程关联的错误消息可能不如关于违反主键约束的错误消息清晰。（这与上面的“1”有关。）

就关系模型而言，我认为没有任何后果。（也就是说，只要将主键约束替换为行为相同的声明性约束。）