数据库中的 UUID

UUID (通用唯一标识符) 是在数据库中使用的 128 位值,除其他外,用于唯一标识表条目。 它们表示为一个十六进制字符串,分为由连字符分隔的五组(示例: 09fe49b3-4d2b-471c-ac04-36c9e706b85f)。 有 很多的 讨论 关于 UUID 在数据库中的优缺点——它们在分布式系统中是不可或缺的。


因此,在微服务和多租户应用程序中,值得考虑引入 UUID。 在 PHP 框架Laravel中从数据类型 BigInteger 切换到 UUID( RFC 4122规范中 UUID 版本 4 的可排序变体)很快完成:首先,我们创建一个新特征:

2aa7136d977617159be1834eaf40e871

然后我们添加我们所有的模型:

2aa7136d977617159be1834eaf40e871

在 Laravel 9⁺ 中这更容易:在这里我们已经准备好使用HasUuids特征。 或者,该框架还提供对相关但仍然相当未知的数据类型ULID的支持,由于更好的可读性和可排序性,这可能会很有趣。

困难的部分是现有数据的迁移。 大致可以如下进行:

  1. 向所有表添加新的具有空值的 UUID 列
    (每个都基于所有主键和外键列)
  2. 将 UUID 值写入新列
    (使用升序主键加上更新的外键)
  3. 删除原始列
  4. 重命名新列

这里有几个挑战:迁移过程需要很长时间,并且新列会附加到表的末尾(可能的解决方案: resort columns )。 一种更直接的方法是直接转换列。

如果你把那个 PostgreSQL 第一,您可以(当然,在之前的备份之后)运行以下查询,例如(在此之前,您可以删除您在 Z 中排除的所有表。 19/31 替换,以及Z中自己的特殊规则。 37/39 add) 并复制从它生成的所有查询:

2aa7136d977617159be1834eaf40e871

如果您现在一起运行生成的查询,那么您已经在很短的时间内迁移了数据库。 虽然由此生成的 UUID 不符合 v4 规范,但它们在字典上与先前条目的顺序相同,不会与新的 UUID 冲突(在 v4 的第 3 组中总是有一个 4, 在迁移的变体中总是一个 0),这也意味着新的 UUID 总是大于迁移的 UUID。

之后建议删除所有 Laravel 缓存(php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) 和运行会话 (rm -f storage/framework/sessions/*) 清空。 当然,整个事情也可以在 Laravel 迁移中实现:

2aa7136d977617159be1834eaf40e871

转换后,在未来的迁移中使用 bigIncrements 或者。 bigInteger 然后 uuid:

2aa7136d977617159be1834eaf40e871

背部