他们给出了比我更好的技术答案。 我只能补充一下这个话题:

如果你想要一些不被允许/可接受的东西，这是一个很好的理由后退一步。

理解为什么这是不可接受的核心原因。 挖掘更多的文档/期刊文章/网络等。 分析/审查当前设计并指出主要缺陷。 在新设计中考虑和测试每一个步骤。 永远向前看，努力创造适应性的解决方案。

希望它能帮助到一些人。

(我一直在研究这些，很多)

候选键——唯一标识表行所需的最小列组合。 复合键- 2个或更多列。

一个表中可以存在多个候选键。 主键-只有一个候选键是由我们选择的 备用键-所有其他候选键 主键和备用键都可以是复合键

来源: https://en.wikipedia.org/wiki/Superkey https://en.wikipedia.org/wiki/Candidate_key https://en.wikipedia.org/wiki/Primary_key https://en.wikipedia.org/wiki/Compound_key

只能有一个主键，但可以在主键中有多个列。

你也可以在你的表上有唯一索引，这将有点像一个主键，因为它们将强制唯一的值，并将加快这些值的查询。

同时有两个主键是不可能的。但是(假设你没有把复合键搞砸)，你可能需要的是让一个属性是唯一的。

CREATE t1(
c1 int NOT NULL,
c2 int NOT NULL UNIQUE,
...,
PRIMARY KEY (c1)
);

However note that in relational database a 'super key' is a subset of attributes which uniquely identify a tuple or row in a table. A 'key' is a 'super key' that has an additional property that removing any attribute from the key, makes that key no more a 'super key'(or simply a 'key' is a minimal super key). If there are more keys, all of them are candidate keys. We select one of the candidate keys as a primary key. That's why talking about multiple primary keys for a one relation or table is being a conflict.

是的，在SQL中是可能的， 但是我们不能在MsAccess中设置多个主键。 我不知道其他数据库的情况。

CREATE TABLE CHAPTER (
    BOOK_ISBN VARCHAR(50) NOT NULL,
    IDX INT NOT NULL,
    TITLE VARCHAR(100) NOT NULL,
    NUM_OF_PAGES INT,
    PRIMARY KEY (BOOK_ISBN, IDX)
);

正如其他人所指出的，可以有多列主键。 但是需要注意的是，如果有一些函数依赖关系不是由键引入的，那么应该考虑规范化关系。

例子:

Person(id, name, email, street, zip_code, area)

id ->名称、电子邮件、街道、zip_code和区域之间可能存在功能依赖关系 但zip_code通常与区域相关联，因此zip_code ->区域之间存在内部函数依赖关系。

因此，可以考虑将它分割到另一个表中:

Person(id, name, email, street, zip_code)
Area(zip_code, name)

所以它和第三种形式是一致的。