数据库设计 – 每个表都应该有一个单字段代理/人工主键吗？

我理解代理/人工密钥的一个好处 – 它们不会改变,这可能非常方便.无论是单场还是多场,都是如此 – 只要它们是“人造的”.

但是,将自动递增整数字段作为每个表的主键有时似乎是一个政策问题.拥有这样一个单字段密钥以及为什么(或者为什么不是),这总是最好的主意吗？

要明确的是,这个问题不是关于人工与自然 – 而是关于所有人工关键是否应该是单场的

解决方法

在某些情况下,您不需要代理或人工密钥：

>纯交叉表.如果没有风险的话
交叉点是外键的目标,如果有的话
或没有交叉点吸引独立属性的风险
(那就是FK与两个父表之外的东西)然后你
可以通过使用FK组合作为公平的PK来逃脱
置信度.
>使用静态业务键查找表.如果您有查找
具有唯一业务密钥的表,该密钥在您的外部固定
商业,没有任何改变的机会
实用的目的,然后直接使用业务键即可
事情比较简单.一个例子可能是州或省的名单
代码或ANSI标准号列表等.
>包含从多个独立整合的数据的表
源.如果您的系统必须有许多数据源
然后,在总公司说,一起把它放在一张桌子里
有时您需要一个包含源系统密钥的复合密钥
值和指示源系统是什么的代码.

在某些情况下,旧忠实单调递增的整数代理键不理想.您可以拥有字母数字代理的密钥.这些可能包括：

>您需要合并多个独立数据的情况
源.为避免密钥冲突,您可以使用GUID而不是
IDENTITY键.
>您被迫使用非数字键的情况
表示.假设你有一个车牌数据库.
您的密钥可以是字母数字值而不是纯数字.
>某些外部要求迫使您申请的情况
压缩到您的键值.而不是使用10位数
int32你可以使用六个基数36位数.

为什么大部分时间都是？这个问题的最根本的答案是,如果你需要修改任何表上的主键值,它就是纯粹的地狱.由于用户可以看到或触摸的几乎任何东西都可能在某些时候受到更新,因此使用可见的键值会引发纯粹的地狱.使用代理键可以防止您陷入此陷阱.

话虽如此,请记住,YAGNI有应用这个概念的空间.您不需要将具有IDENTITY键的代码表强制插入到模式的每个角落中,以防万一有人决定您员工表中男性性别的符号需要从M更改为X或傻.

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!