Nin*_*Lee 6 primary-key auto-increment surrogate-key
我的问题是关于自然键和auto_increment整数作为主键.
例如,我有表A和B和A_B_relation.A和B可能是某个对象,并A_B_realtion记录A和B的多对多关系.
A和B都有自己的全局唯一ID,例如UUID.UUID可供用户使用,这意味着用户可以通过UUID查询A或B.
有两种方法可以设计表的主键.
A_B_relation将整数引用为FK.A_B_relation将UUID引用为FK.例如,用户想要通过A的UUID查询与A关联的所有B的信息.
对于第一种情况,查询流程如下:
First, query A's integer primary key by UUID from `A`.
And then, query all the B's integer primary key from `A_B_relation`.
At last, query all the B's info from `B`.
对于后一种情况,流程如下:
Query all the B's UUID from the `A_B_relation` by A's UUID.
Query all the B's info from `B`.
所以我认为,后一种情况更方便.这是正确的吗？后一种情况的不足之处是什么？
小智 7
根据我的意见,使用自动增量键的自然键的便利性取决于您提供的程序解决方案.这两种方法都有利有弊.因此,最佳解决方案是正确理解两种关键类型,分析您尝试提供的业务解决方案类型,并选择适当的主键类型.
自然键是一列或一组列,我们可以用它来唯一地标识表中的记录.这些列包含与表的其余列有关系的实际数据.
自动递增的密钥,也称为代理密钥,是单个表列其中包含唯一的数值,可用于唯一标识表中的单行数据.当记录插入表并且与行的其余数据没有关系时,这些值是在运行时生成的.
使用自然键的主要优点是它具有自己的含义,并且需要与其他表的连接较少,就好像我们使用代理键一样,我们需要连接到外键表以获得我们用自然键得到的结果.
但是说我们无法从单个表中获取所需的所有数据,并且必须与另一个表连接才能获得所需的所有数据.然后使用代理键而不是自然键是方便的,因为大多数时候自然键是字符串并且大小比代理键大,并且使用更大的值来连接表将花费更多时间.
一把自然的钥匙有它自己的意思.因此,在搜索记录时,使用自然键比代理键更有利.但随着时间的推移,我们的程序逻辑会发生变化,我们必须改变自然键值.这将很困难,并将导致对所有外键关系的级联效应.我们可以使用代理键来克服这个问题.由于代理键与行的其余值没有关系,因此逻辑的更改不会对代理键产生影响.
同样,我认为使用代理键或自然键的便利性和不便完全基于您提供的解决方案.