Database design 何时应该使用复合主键？

ETA：我的问题是基于保持一个最佳的数据库。对于ProjectUserBooleanAttribute，使用全复合主键在数据库性能/大小上有什么区别，其中可能会有PUAT_Id和UserID的索引，以及使用自动递增PK的非复合表，但同时有PUAT_Id和UserID的索引？从进一步的阅读来看，如果我采用非复合方法，我将不得不在这两列上创建一个唯一的索引。我还需要在这两列上创建索引吗？如果是这样的话，这难道不意味着表中的每一列都有自己的索引吗

这是数据库大小（索引）与性能的典型矛盾吗

---

因此，我希望创建以下实体

• 计划
• 使用者
• ProjectUserAttributeType

在这个简化的示例中，我的所有ProjectUserAttributeType都将是布尔值，因此我只显示ProjectUserBooleanAttribute表

假设我想创建两个名为银和金的布尔ProjectUserAttributeType。我只需在projectUserAttributeType中创建两行即可。现在，如果我想将一个用户指定为具有该属性，我将向ProjectUserBooleanAttribute添加一行

DBA警告我，出于性能原因，一般不要使用复合主键。然而，在这种情况下，我看不到不使用复合材料会带来什么好处。在这两种情况下，我都需要确保所有列的ProjectUserBooleanAttribute都具有非空且唯一的值。我当然也需要索引

注意：我的最终目标是能够查询我的数据库并找到具有特定属性组合的所有用户。我将加入表以按项目进行筛选，然后使用where子句进行进一步筛选。举几个例子：

• （金或银）
• （金或银）
• （（金或银）而非（铜））

复合主键

与非复合PK的对比

---

关系数据库有两种主要设计：

• 自然键
• 身份证

对于自然密钥，您可以使用给定的密钥：项目由其项目编号标识，用户由其登录名或编号标识，等等。这通常会导致复合（或复合）密钥：

• 项目（项目编号，名称，…）
• 用户（用户名、名、姓……）
• 项目用户（项目编号、用户名、角色等）

表project_user有一个复合键：项目编号加上唯一标识记录的用户名，告诉我们谁在处理哪个项目

使用ID，您通常会添加一个仅用于链接记录且对用户没有意义的技术ID：

• 项目（项目id，项目编号，名称，…）
• 用户（用户id、用户名、名、姓……）
• 项目用户（项目用户id，项目id，用户id，角色，…）

这些表包含相同的字段加上ID，您需要与自然键加上ID上的约束相同的唯一和非空约束

当然，只有当有任何表需要该引用时，project_user中的project_user_id才是必需的。但通常每个表都会得到一个ID，不管是否需要，只是为了让它们看起来都一样（因此ID已经存在，以备以后需要）

乍一看，基于IDs的数据库似乎只需要更多的工作、更多的索引，而什么也得不到，但事实并非如此。通常选择ID概念，因为它提供了更多的自由。例如：如果项目编号可能发生变化，会发生什么？对于自然键，项目编号在许多表中，必须以某种方式进行cascadingly更新，这可能会成为一项相当艰巨的任务。在ID数据库中，只需在一个位置更改项目ID

如果突然间项目编号只在公司内部是唯一的，那会发生什么呢？在基于ID的数据库中，您可以将公司ID添加到projects表中，在公司ID和项目编号上添加唯一索引，然后使用它。对于自然键，必须将公司编号（ILN？人工编号？）添加到主键，并且必须在所有子表中引入。所以：当你设计一个带有自然键的数据库时，你必须仔细考虑，以获得稳定的自然键——有时没有，然后你必须发明一些。有了ID，您就不会太在意字段是否可以更改。因此，基于ID的数据库更容易实现

然后是等级制度。假设您的数据库中有多家公司，每家公司都有自己的项目和仓库

自然关键点：

• 公司（公司代码，名称，…）
• 项目（公司代码、项目编号、名称等）
• 仓库（公司代码、仓库编号、地址等）
• 库存（公司代码、仓库编号、物料编号、金额等）

ID:

• 公司（公司id，名称，…）
• 项目（项目id，项目编号，名称，公司id，…）
• 仓库（仓库id，地址，公司id，…）
• 库存（库存id、仓库id、物料id、金额等）

使用ID概念，您不必在stock表中再次命名company\u ID，因为它是从父表中知道的。存储它甚至是多余的，而在自然键概念中它是需要的，因为它是o部分