UUID (Объекты универсального уникального идентификатора) — это 128-битные значения, которые используются в базах данных, помимо прочего, для уникальной идентификации записей таблицы. Они представлены в виде шестнадцатеричной строки, разделенной на пять групп, разделенных дефисами (пример: 09fe49b3-4d2b-471c-ac04-36c9e706b85f
). Есть многочисленные Обсуждения о преимуществах и недостатках UUID в базах данных — они незаменимы в распределенных системах.
Поэтому в микросервисах и приложениях с несколькими арендаторами стоит подумать о введении UUID. Переход с типа данных BigInteger на UUID (сортируемый вариант UUID версии 4 из спецификации RFC 4122 ) в PHP-фреймворке Laravel выполняется быстро: сначала мы создаем новый трейт:
2aa7136d977617159be1834eaf40e871
Затем мы добавляем все наши модели:
2aa7136d977617159be1834eaf40e871
В Laravel 9⁺ это еще проще: здесь у нас уже есть трейт HasUuids , готовый к использованию. В качестве альтернативы фреймворк также предлагает поддержку связанного, но все еще довольно неизвестного типа данных ULID , который может быть интересен из-за лучшей читабельности и сортируемости.
Сложной частью является миграция существующих данных. Примерно можно было бы поступить следующим образом:
- Добавить новые столбцы UUID с пустыми значениями во все таблицы
(каждый основан на всех столбцах первичного и внешнего ключа) - Запишите значения UUID в новые столбцы
(с восходящими первичными ключами плюс обновленные внешние ключи) - Удалить исходные столбцы
- Переименовать новые столбцы
Здесь есть несколько проблем: процесс миграции занимает много времени, а новые столбцы добавляются в конец таблицы (возможное решение: курортные столбцы ). Гораздо более прямым способом является непосредственное преобразование столбцов.
Если вы положите это PostgreSQL one можно (после предыдущего бэкапа, разумеется) выполнить следующий запрос, например (перед этим можно удалить все таблицы, которые вы исключили в Z. 19
/31
заменить, а также собственные специальные правила в Z. 37
/39
add) и копирует все сгенерированные из него запросы:
2aa7136d977617159be1834eaf40e871
Если вы теперь запустите сгенерированные запросы вместе, вы перенесете базу данных за короткое время. Хотя сгенерированные таким образом UUID не соответствуют спецификации v4, лексиграфически они расположены в том же порядке, что и предыдущие записи, не конфликтуют с новыми UUID (в 3-й группе в v4 всегда есть 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