我什么时候应该使用复合主键？

Question

ETA:我的问题是基于保持最佳数据库.具有ProjectUserBooleanAttribute的所有复合主键(可能具有PUAT_Id和UserID的索引)和使用自动增量PK的非复合表但是具有PUAT_Id和UserID的索引之间的数据库性能/大小有何不同？从进一步阅读看来,如果我采用非复合方法,我将不得不在这两列上创建一个唯一索引.我还需要在这两列上创建索引吗？如果是这样,这实际上不意味着该表中的每一列都有它自己的索引吗？

这是数据库大小(索引)与性能的典型困境吗？

---

所以我想要创建以下实体

• 项目
• 用户
• ProjectUserAttributeTypes

在这个简化的示例中,我的所有ProjectUserAttributeTypes都将是boolean,因此我只显示ProjectUserBooleanAttribute表.

假设我想创建两个名为Silver和Gold的布尔ProjectUserAttributeType .我只想在ProjectUserAttributeTypes中创建两行.现在,如果我想将用户指定为具有该属性,我将向ProjectUserBooleanAttribute添加一行

出于性能原因,DBA已经警告我不要使用复合主键.然而在这种情况下,我没有看到我使用复合材料获得了什么.在这两种情况下,我都需要确保ProjectUserBooleanAttribute对所有列都具有非null和唯一值.我肯定也需要索引.

注意:我的最终目标是能够查询我的数据库并查找具有某些属性组合的所有用户.我会加入表来按项目过滤,然后使用where子句进一步过滤.几个例子:

• (金或银)
• (GOLD XOR SILVER)
• ((金或银)而不是(铜))

复合PK

与非复合PK

Answer 1

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

• 自然键
• 标识

使用自然键,您可以使用给定的键:项目由项目编号标识,用户通过登录名或编号标识等.这通常会导致复合(或复合)键:

• project(project_no,name,...)
• user(user_name,first_name,last_mname,...)
• project_user(project_no,user_name,role,...)

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

使用ID,您通常会添加一个技术ID,该ID仅用于链接记录,对用户没有任何意义:

• project(project_id,project_no,name,...)
• user(user_id,user_name,first_name,last_mname,...)
• project_user(project_user_id,project_id,user_id,role,...)

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

当有任何需要该引用的表时,project_user中的project_user_id当然是必需的.但是,通常每个表都会获得一个ID,无论是否需要,只是为了使它们看起来都相似(因此ID已经存在,以防以后需要它们).

乍一看似乎基于ID的数据库只是更多的工作,更多的索引和没有获得,但事实并非如此.通常选择ID概念,因为它提供了更多自由.一个例子:如果项目编号可以改变,会发生什么？使用自然键,项目编号在许多表中,并且必须以某种方式级联更新,这可能成为一项非常重要的任务.在ID数据库中,您只需在一个位置更改项目ID.

如果突然项目数量在公司内部是唯一的,那么帽子会发生吗？在基于ID的数据库中,您可以将company_id添加到项目表中,在company_id和project_no上添加唯一索引并完成它.使用自然密钥,必须将公司编号(ILN？人工编号？)添加到主密钥中,并且必须在所有子表中引入.所以:当你使用自然键设计一个数据库时,你必须全力以赴地获得稳定的自然键 - 有时候没有,然后你必须发明一些.使用ID,您不必关心字段是否可以更改.因此,基于ID的数据库更容易实现.

然后有层次结构.可以说,您的数据库中有几家公司,每家公司都有自己的项目,拥有自己的仓库.

自然键:

• 公司(company_code,name,...)
• item(company_code,item_no,name,...)
• 仓库(company_code,warehouse_no,地址,......)
• stock(company_code,warehouse_no,item_no,amount,...)

标识:

• 公司(company_id,名称,...)
• item(item_id,item_no,name,company_id,...)
• 仓库(warehouse_id,address,company_id,...)
• 库存(stock_id,warehouse_id,item_id,金额,......)

使用ID概念,您不必在stock表中再次命名company_id,因为它从父表中已知.存储它甚至是多余的,而在自然键概念中它是必需的,因为它是复合键的一部分,没有它我们将丢失到其父表的链接.有些人认为这种纯度是ID概念优于自然键的一大优势.然而,它有一个缺点.在自然密钥数据库中,保证公司的物品在公司的仓库中,因为公司是库存表的关键部分.使用ID概念,链接的仓库记录可能属于公司1,链接的项目记录可能属于公司2.由DBMS无法阻止我们的错误插入语句导致的数据不一致.使用自然键这样的错误不会发生.

如果我想知道公司有多少股票,我只需从自然键中选择股票.但我必须从股票和另一张表中选择将公司放入ID数据库.

对于多层次结构,当数据库基于ID时,您可能会获得涉及许多更多表的查询.到目前为止,我还没有看到基于ID的数据库优于使用自然键的数据库.但到目前为止,我已经看到基于自然密钥的数据库优于基于ID的数据库.这可能是因为我主要看到有很多层次结构的大型数据库.

至于你的数据库:它似乎是基于ID的,只要项目ID和用户ID只是技术内部数字 - 否则你的数据库将是一个混合概念(自然项目编号,自然用户ID,ProjectUserBooleanAttribute的技术ID).所以你的问题与复合键没有关系.

PUAT_ID和UserID都必须在ProjectUserBooleanAttribute中,它们不是null,并且您应该对它们有唯一约束(唯一索引).因此,无论您是否将此"主键"称为"主键",它们都具有主键所需的所有品质.是否添加技术ID只是为了它的外观.它并没有真正改变任何事情.这个概念保持不变.

在自然键概念中,您将使字段成为主键.但是,你不会有一个PUAT_Id,而是一些复合键(ProjectId加上AttributeType？).

在技​​术ID概念中,您不会将其作为主键,而是使字段不为空并添加唯一约束(这使其成为键,只有它不被称为"主").然后添加技术ID作为主键或使表没有ID,因此没有主键.没关系.如果有人要求钥匙,请给他们身份证,如果没有,你可以不用它.只要任何其他表都不需要,它就是多余的.