UUIDoj (Universale Unika Identigiloj) estas 128-bitaj valoroj, kiuj estas uzataj en datumbazoj, interalie, por unike identigi tabelajn enirojn. Ili estas prezentitaj kiel deksesuma ŝnuro dividita en kvin grupojn apartigitajn per streketoj (Ekzemplo: 09fe49b3-4d2b-471c-ac04-36c9e706b85f
). Estas multnombraj Diskutoj pri la avantaĝoj kaj malavantaĝoj de UUID-oj en datumbazoj - ili estas nemalhaveblaj en distribuitaj sistemoj.
En mikroservoj kaj plur-luantaj aplikoj, indas do konsideri enkonduki UUID-ojn. Ŝanĝi de datumtipo BigInteger al UUID (ordigebla varianto de UUID-versio 4 de la RFC 4122- specifo) en la PHP-kadro Laravel estas farita rapide: Unue, ni kreas novan trajton .:
2aa7136d977617159be1834eaf40e871
Poste ni aldonas ĉiujn niajn modelojn:
2aa7136d977617159be1834eaf40e871
En Laravel 9⁺ tio estas eĉ pli facila: ĉi tie ni jam havas la trajton HasUuids preta por uzi. Alternative, la kadro ankaŭ ofertas subtenon por la rilata, sed ankoraŭ sufiĉe nekonata datumtipo ULID , kiu povus esti interesa pro pli bona legebleco kaj ordigo.
La malfacila parto estas la migrado de ekzistantaj datumoj. Proksimume oni povus procedi jene:
- Aldonu novajn UUID-kolumnojn kun malplenaj valoroj al ĉiuj tabeloj
(ĉiu bazita sur ĉiuj primaraj kaj fremdaj ŝlosilaj kolumnoj) - Skribu UUID-valorojn al la novaj kolumnoj
(kun ascendantaj ĉefŝlosiloj kaj plie ĝisdatigitaj fremdaj ŝlosiloj) - Forigu originalajn kolumnojn
- Alinomi novajn kolumnojn
Estas pluraj defioj ĉi tie: La migra procezo prenas longan tempon kaj novaj kolumnoj estas almetitaj al la fino de la tabelo (ebla solvo: feriaj kolumnoj ). Multe pli rekta maniero estas transformi la kolumnojn rekte.
Se vi metas tion PostgreSQL unu, vi povas (post antaŭa sekurkopio, kompreneble) ruli la sekvan demandon, ekzemple (antaŭ tio vi povas forigi ĉiujn tabelojn, kiujn vi ekskludas en Z. 19
/31
anstataŭigi, same kiel proprajn specialajn regulojn en Z. 37
/39
add) kaj kopias ĉiujn demandojn generitajn de ĝi:
2aa7136d977617159be1834eaf40e871
Se vi nun kuras la generitajn demandojn kune, vi migris la datumbazon ene de mallonga tempo. Dum la UUID-oj tiel generitaj ne konformas al la v4-specifo, ili estas leksigrafie en la sama sinsekvo kiel la antaŭaj enskriboj, ne kolizias kun novaj UUID-oj (en la tria grupo en v4 ĉiam estas 4
, ĉiam unu en la migrita varianto 0
), kio ankaŭ signifas, ke novaj UUIDoj ĉiam estas pli grandaj ol la migritaj UUIDoj.
Post tio oni rekomendas forigi ĉiujn Laravel-kaŝmemorojn (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*
) kaj kurantaj sesioj (rm -f storage/framework/sessions/*
) malplenigi. Kompreneble, la tuta afero ankaŭ povas esti efektivigita ene de Laravel-migrado:
2aa7136d977617159be1834eaf40e871
Post la konvertiĝo oni uzas en estontaj migradoj anstataŭe bigIncrements
aŭ. bigInteger
tiam uuid
:
2aa7136d977617159be1834eaf40e871