主键的 UUID 或序列？

小开

可以使用 UUID 作为表中的主键，因为它是唯一的。但是要记住，UUID 将占用更多的空间，相对于 SEQUENT。而且他们也不是很快。但是，是的，它们肯定是唯一的，因此可以保证获得一致的数据。

你亦可参考:

小开

最佳答案

PostgreSQL 中的 sequence与 MySQL 中的 AUTOINCREMENT完全相同。sequence比 uuid更有效率，因为它是8字节，而 uuid是16字节。您可以使用 uuid作为主键，就像大多数其他数据类型一样。

但是，我看不出这与屏蔽用户 ID 有什么关系。如果希望从其他用户中屏蔽某个用户的 ID，则应该仔细管理表特权和/或使用(例如) md5()散列该 ID。

如果希望保护包含用户数据的表免受试图猜测其他 ID 的黑客的窥探，那么 uuid类型是一个很好的选择。包装 uuid-ossp有几种口味。版本4是最好的选择，因为它有122个随机位(其他6个用于识别版本)。您可以像下面这样创建一个主键:

id uuid PRIMARY KEY DEFAULT uuid_generate_v4()

然后你就再也不用担心了。

PostgreSQL 13 +

现在可以使用内置函数 gen_random_uuid()获得版本4的随机 UUID。

小开

多年来，我使用 PK 和 FK 作为数字序列值来开发数据库应用程序。这种方法非常有效，但是在最近几年，当我们创建云应用程序时，我们将在应用程序之间交换信息，并且我们将在我们开发的各种应用程序之间进行集成，我们意识到在我们的 API 中使用顺序 ID 最终会产生一种效果。

在一些应用程序中，我们必须找到通过 API 调用发送的 ID (目标应用程序的 ID) ，另一方面，在我们所有的应用程序中，除了连续的 PK/FK 列之外，还有一个在 API 调用中没有使用的 UUID 列。在这个场景中，我们决定重写 API，以便使用 UUID 列。

这解决了一些问题，因为我们的一个桌面应用程序将其数据迁移到另一个云应用程序，这个云应用程序也使用了 PK/FK 列。在迁移这些数据时，我们必须更改新序列的 PK/FK 的值，因为这些序列可能会在桌面应用程序的值和云应用程序的值之间发生冲突。考虑到这一点，我们选择将云应用程序 PKs/FK 切换到 UUID，因为来自桌面应用程序的数据有一个 UUID 列。

然后的问题是通过将 INT 列(PKs 和 FK)转换为 UUID 列而不丢失表信息来转换云应用程序表。这是一个很大的任务，但是它变得更容易了，因为我最终构建了一个应用程序，使这个更改变得更容易。应用程序将每个 PK/FK 整数列更改为 UUID，保留数据和关系。有兴趣的人可以点击以下链接:

Https://claytonbonelli.github.io/int_pk2uuid_pk/