Question

我的问题是关于自然键和auto_increment整数作为主键。

例如，我有表A和B以及A_B_relation。 A和B可能是某个对象，A_B_realtion记录A和B的多对多关系。

A和B都有自己的全局唯一ID，例如UUID。用户可以使用UUID，这意味着用户可以通过UUID查询A或B.

有两种方法可以设计表的主键。

使用auto_increment整数。 A_B_relation将整数引用为FK。
使用UUID。 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`.

所以我认为，后一种情况更方便。这是正确的吗？后一种情况的不足是什么？

Answer 1

根据我的意见，使用自动增量键的自然键的便利性取决于您提供的程序解决方案。这两种方法都有利有弊。因此，最佳解决方案是正确理解两种关键类型，分析您尝试提供的业务解决方案类型，并选择适当的主键类型。

自然键是列或一组列，我们可以使用它来唯一地标识表中的记录。这些列包含与表格其余列有关系的实际数据。

自动递增密钥，也称为代理键是单表列，其中包含可用于唯一标识单个值的唯一数值表中的数据行。当记录插入表并且与行的其余数据没有关系时，这些值是在运行时生成的。

使用自然键的主要优点是它具有自己的意义，并且与其他表需要较少的连接，就好像我们使用代理键一样，我们需要连接到外键表来获得结果我们得到了自然的钥匙。
但是说我们无法从单个表中获取所需的所有数据，并且必须与另一个表连接才能获得所需的所有数据。然后使用代理键而不是自然键是方便的，因为大多数时候自然键是字符串并且大小比代理键大，并且使用更大的值来连接表将花费更多时间。

一把自然的钥匙具有它自己的意义。因此，在搜索记录时，使用自然键比代理键更有利。但随着时间的推移，我们的程序逻辑会发生变化，我们必须改变自然键值。这将很困难，并将导致对所有外键关系的级联效应。我们可以使用代理键来克服这个问题。由于代理键与行的其余值没有关系，因此逻辑的更改不会对代理键产生影响。

同样，我认为使用代理键或自然键的方便性和不便完全基于您提供的解决方案。

自然键vs auto_increment键作为主键

1 个答案: