UUID (Universellt unika ID -enifierare) är 128-bitars värden som bland annat används i databaser för att unikt identifiera tabellposter. De representeras som en hexadecimal sträng uppdelad i fem grupper separerade med bindestreck (exempel: 09fe49b3-4d2b-471c-ac04-36c9e706b85f). Det finns talrik Diskussioner om fördelarna och nackdelarna med UUID i databaser - de är oumbärliga i distribuerade system.
I mikrotjänster och multi-tenancy-applikationer är det därför värt att överväga att införa UUID. Byte från datatyp BigInteger till UUID (en sorterbar variant av UUID version 4 från RFC 4122- specifikationen) i PHP-ramverket Laravel görs snabbt: Först skapar vi en ny egenskap:
2aa7136d977617159be1834eaf40e871
Sedan lägger vi till alla våra modeller:
2aa7136d977617159be1834eaf40e871
I Laravel 9⁺ är detta ännu enklare: här har vi redan HasUuids- egenskapen redo att användas. Alternativt erbjuder ramverket också stöd för den relaterade, men fortfarande ganska okända datatypen ULID , vilket kan vara intressant på grund av bättre läsbarhet och sorterbarhet.
Den svåra delen är migreringen av befintlig data. Grovt sett skulle man kunna gå tillväga enligt följande:
- Lägg till nya UUID-kolumner med tomma värden till alla tabeller
(var och en baserad på alla primära och främmande nyckelkolumner) - Skriv UUID-värden till de nya kolumnerna
(med stigande primärnycklar och uppdaterade främmande nycklar) - Ta bort originalkolumner
- Byt namn på nya kolumner
Det finns flera utmaningar här: Migreringsprocessen tar lång tid och nya kolumner läggs till i slutet av tabellen (möjlig lösning: utvägskolumner ). Ett mycket mer direkt sätt är att transformera kolumnerna direkt.
Om du lägger PostgreSQL För att göra detta kan du (efter en säkerhetskopia förstås) köra följande fråga, till exempel (i förväg kan du lista alla tabeller du vill exkludera i Z). 19/31 ersätt såväl som dina egna specialregler i Z. 37/39 add) och kopierar alla frågor som genereras från den:
2aa7136d977617159be1834eaf40e871
Om du nu kör de genererade frågorna kollektivt har du migrerat databasen inom en kort tid. De UUID som skapas på detta sätt överensstämmer inte med v4-specifikationen, men de är lexikografiskt i samma ordning som de tidigare posterna, kolliderar inte med nya UUID (det finns alltid en i den 3:e gruppen i v4 4, alltid en i den migrerade varianten 0), vilket också innebär att nya UUID alltid är större än de migrerade UUID:erna.
Efter det rekommenderas det att hitta alla Laravel-cacher (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) och löppass (rm -f storage/framework/sessions/*) att tömma. Naturligtvis kan det hela också implementeras inom en Laravel-migrering:
2aa7136d977617159be1834eaf40e871
Efter konverteringen använder man i framtida migrering istället bigIncrements eller. bigInteger sedan uuid:
2aa7136d977617159be1834eaf40e871