每个表都应该有一个单字段代理/人为主键吗？

#1 楼

我要说的不是，不是总是这样，但大多数时候是。.

在某些情况下，您不需要代理键或人工键：



纯交点表。如果没有
交叉点成为外键目标的风险，并且
几乎没有
交叉点吸引独立属性的风险
（即，除了FK之外，两者都是父表），那么您
就可以放心地将FK组合用作具有公平信心的PK。

具有静态业务密钥的查找表。如果您有一个具有唯一业务密钥的查找表，该业务密钥在外部固定在您的业务上，并且出于任何实际目的进行更改的可能性为零，那么直接使用业务密钥可以使事情变得更简单。一个示例可能是州或省份代码列表或ANSI标准编号列表等。

包含从多个独立的
来源合并的数据的表。如果您的系统有许多数据源，必须将这些数据源合并到一个表中，例如在总部，那么
有时您需要一个复合键，其中应包括源系统键
值和指示源系统是什么的代码。

在某些情况下，忠实于单调递增的整数代理键也不理想。您可以使用字母数字替代键。这些可能包括：


您需要合并来自多个独立
源的数据的情况。为避免按键冲突，您可以使用GUID代替
IDENTITY键。
您被迫使用非数字键表示的情况。假设您有一个车牌数据库。
您的密钥可以是字母数字值，而不是纯数字。
某些外部要求迫使您应用的情况
压缩到您的关键值。可以使用6个基数36位数字来代替
int32的10位数字。

为什么大多数时候是的？该问题的最根本答案是，如果您需要修改任何表上的主键值，那简直是地狱。可以想象，由于用户可以看到或触摸的几乎所有东西都可能在某个时刻进行更新，因此使用可见键值会引起混乱。使用代理密钥可以防止您陷入陷阱。

话虽如此，请记住，YAGNI在应用此概念时仍有空间。您无需将带有IDENTITY键的代码表强加到架构的每个角落，以防万一有人认为员工表中的男性符号需要从M更改为X或有些愚蠢的情况。

#2 楼

“取决于”

是：当自然键为宽且非数字时，替代IDENTITY / AUTONUMBER字段会很好。注意：这假定默认情况下在SQL Server和Sybase等中默认发生“ PK”和聚集索引的合并。

否：当两个父键足够时，许多表很多。或者，当自然键较短且固定长度时，例如货币代码

当然，脑残的ORM（读取：（n）休眠）可能会胜过这些规则...

编辑：再次阅读问题

具有2个代理父键的多/许多表将具有多列PK。
但是，它不需要另一个代理列。

如果一个表确实具有代理（IDENTITY等）键，则它不必是多列。

您可以有一个包含代理的超级键，但这将强制执行其他规则（例如，子类型）

#3 楼

我肯定会说，单字段键至少在复合键方面不如复合键重要。这并不是说，如果愿意的话，也就不应该具有单字段代理键，但是我个人更喜欢将最常用作外键目标的键称为主键

在下面的示例中，我将尝试阐明我的观点，其中：



brand是汽车品牌，例如福特，丰田等

dealer是与品牌相关的实体经销店（例如仅销售福特的福特经销店）

model是汽车的类型，例如福特福克斯，福特嘉年华等

/> stock是每个经销商当前的前庭车辆数量br />
，则可以在dealer中插入一行，从而将福特model链接到“丰田”模型。将stock添加到dealer只会使问题变得更糟。另一方面，如果我们将外键保留为主键的一部分，如下所示：

create table brand( brand_id integer primary key );

create table dealer( dealer_id integer primary key, 
                     brand_id integer references brand )

create table model( model_id integer primary key, 
                    brand_id integer references brand )

create table stock( model_id integer references model, 
                    dealer_id integer references dealer, 
                    quantity integer,
                      primary key(model_id, dealer_id) )

现在的规则是，“福特”经销商只能库存“福特”

请注意，在“复合键”示例中，根据偏好，brand_id references brand可能是唯一的，也可能不是唯一的。它不必是唯一的（即备用键），但是通过使其变得唯一（可能有一点存储空间）而损失的很少，并且它非常方便，这就是我通常设置它的方式，例如： br />

create table brand( brand_id integer primary key );

create table dealer( brand_id integer references brand, 
                     dealer_id integer, 
                       primary key(brand_id, dealer_id) )

create table model( brand_id integer references brand, 
                    model_id integer, 
                      primary key(brand_id, model_id) )

create table stock( brand_id integer, 
                    model_id integer, 
                    dealer_id integer, 
                    quantity integer,
                      primary key(brand_id, model_id, dealer_id),
                      foreign key(brand_id, model_id) references model,
                      foreign key(brand_id, dealer_id) references dealer )