UUID (Identifiants universellement uniques) sont des valeurs de 128 bits qui sont utilisées dans les bases de données, entre autres, pour identifier de manière unique les entrées de table. Ils sont représentés sous la forme d'une chaîne hexadécimale divisée en cinq groupes séparés par des traits d'union (Exemple: 09fe49b3-4d2b-471c-ac04-36c9e706b85f). Il y a nombreux Discussion sur les avantages et les inconvénients des UUID dans les bases de données - ils sont indispensables dans les systèmes distribués.
Dans les microservices et les applications multi-locataires, il convient donc d'envisager l'introduction d'UUID. Passer du type de données BigInteger à UUID (une variante triable de l'UUID version 4 de la spécification RFC 4122 ) dans le framework PHP Laravel se fait rapidement : Premièrement, on crée un nouveau trait:
2aa7136d977617159be1834eaf40e871
Ensuite, nous ajoutons tous nos modèles:
2aa7136d977617159be1834eaf40e871
Dans Laravel 9⁺, c'est encore plus simple : ici, nous avons déjà le trait HasUuids prêt à l'emploi. Alternativement, le framework offre également un support pour le type de données associé, mais encore assez inconnu, ULID , ce qui pourrait être intéressant en raison d'une meilleure lisibilité et facilité de tri.
La partie difficile est la migration des données existantes. En gros on pourrait procéder comme suit:
- Ajouter de nouvelles colonnes UUID avec des valeurs vides à toutes les tables
(chacun basé sur toutes les colonnes de clé primaire et étrangère) - Écrivez les valeurs UUID dans les nouvelles colonnes
(avec clés primaires ascendantes plus clés étrangères mises à jour) - Supprimer les colonnes d'origine
- Renommer les nouvelles colonnes
Il y a plusieurs défis ici : Le processus de migration prend beaucoup de temps et de nouvelles colonnes sont ajoutées à la fin du tableau (solution possible : resort columns ). Un moyen beaucoup plus direct consiste à transformer directement les colonnes.
Si tu mets ça PostgreSQLName un, vous pouvez (après une sauvegarde précédente, bien sûr) exécuter la requête suivante, par exemple (avant cela, vous pouvez supprimer toutes les tables que vous excluez dans Z. 19/31 remplacer, ainsi que ses propres règles spéciales dans Z. 37/39 add) et copie toutes les requêtes générées à partir de celui-ci:
2aa7136d977617159be1834eaf40e871
Si vous exécutez maintenant les requêtes générées ensemble, vous avez migré la base de données en peu de temps. Bien que les UUID ainsi générés ne soient pas conformes à la spécification v4, ils sont lexigraphiquement dans le même ordre que les entrées précédentes, n'entrent pas en collision avec de nouveaux UUID (dans le 3ème groupe en v4 il y a toujours un 4, toujours un dans la variante migrée 0), ce qui signifie également que les nouveaux UUID sont toujours plus grands que les UUID migrés.
Après cela, il est recommandé de supprimer tous les caches Laravel (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) et en cours d'exécution (rm -f storage/framework/sessions/*) à vider. Bien sûr, le tout peut également être implémenté dans une migration Laravel:
2aa7136d977617159be1834eaf40e871
Après la conversion, on utilise à la place dans les futures migrations bigIncrements ou. bigInteger ensuite uuid:
2aa7136d977617159be1834eaf40e871