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 plus 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 sätter det PostgreSQL För det första kan du (efter en tidigare säkerhetskopiering förstås) köra följande fråga, till exempel (innan det kan du ta bort alla tabeller som du exkluderar i Z. 19/31 ersätta, samt 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 tillsammans har du migrerat databasen på kort tid. Även om de sålunda genererade UUID inte överensstämmer med v4-specifikationen, är de lexigrafiskt i samma ordning som de tidigare posterna, kolliderar inte med nya UUID (i den 3:e gruppen i v4 finns det alltid en 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 ta bort 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