primary-key - 自然键 vs auto_increment 键作为主键

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

根据我的观点，使用自增键的自然键的方便性取决于您提供的程序解决方案。这两种方法各有利弊。所以最好的解决方案是正确理解这两种键类型，分析您尝试提供的业务解决方案类型并选择合适的主键类型。
自然键 是一列或一组列，我们可用于唯一标识表中的记录。这些列包含与表的其余列有关系的真实数据。
自动递增 key ，也称为 代理键 是单个表列，其中包含唯一的数值，可用于唯一标识表中的单行数据。这些值是在运行时将记录插入到表中时生成的，并且与行的其余数据没有关系。

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

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

同样，正如我所看到的，完全基于您提供的解决方案使用代理键或自然键的方便和不便。