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

Question

是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 &&) 
); 

是否需要显式声明的party_address_is_billing表PRIMARY KEY？由于排除约束指定了唯一标识符（(address_id, party_id, transaction_time)），因此明确指定PRIMARY KEY (address_id, party_id, transaction_time)似乎是多余的。它也会创建一个额外的和不必要的索引。

• 没有在表上指定PRIMARY KEY会产生什么后果？

Answer 1

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

在你的5NF表中，如果你声明关键字为not null unique (address_id, party_id)，你根本不会改变底层的依赖关系。这就是你必须从关系角度来关注的东西 - 替代的语法不会搞垮潜在的依赖关系。 （这意味着关系模型不关心实现的“额外和不必要的索引”）。

因此，在“party_address_is_billing”中，如果排除约束的行为像一个关键约束，我认为你很好作为关系模型而言。

未在表上指定PRIMARY KEY会导致什么后果？

1. 如果更换另一种声明约束的行为上相同的主键约束，你可能会惊讶的维护程序员。请参阅文章Principle of least astonishment。

2. 您可能还会让框架程序员更加努力地工作。许多框架不仅要求PRIMARY KEY约束，还要求约束是代理整数。 （这不是真正的关系问题。）

3. 某些软件工程（CASE）工具可能会阻塞排除约束。

4. 与违反排除约束的进程相关的错误消息可能不如关于违反主键约束的错误消息清楚。 （这涉及到“1”，上面。）

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