UUID-ներ (Համընդհանուր եզակի նույնացուցիչներ) 128-բիթանոց արժեքներ են, որոնք օգտագործվում են տվյալների բազաներում, ի թիվս այլ բաների, աղյուսակի մուտքերը եզակիորեն նույնականացնելու համար: Դրանք ներկայացված են որպես տասնվեցական տող, որը բաժանված է հինգ խմբի՝ բաժանված գծիկներով (Օրինակ: 09fe49b3-4d2b-471c-ac04-36c9e706b85f) Կա բազմաթիվ Քննարկումներ տվյալների բազաներում UUID-ների առավելությունների և թերությունների մասին. դրանք անփոխարինելի են բաշխված համակարգերում:
Միկրոծառայությունների և բազմավարձակալության հավելվածներում, հետևաբար, արժե մտածել UUID-ների ներդրման մասին: Տվյալների BigInteger տիպից անցնելը UUID-ի ( RFC 4122 ճշգրտման UUID տարբերակի 4-ի տեսակավորվող տարբերակ) PHP շրջանակում Laravel- ում կատարվում է արագ. Նախ՝ մենք ստեղծում ենք նոր հատկանիշ ։:
2aa7136d977617159be1834eaf40e871
Հետո ավելացնում ենք մեր բոլոր մոդելները:
2aa7136d977617159be1834eaf40e871
Laravel 9⁺-ում դա նույնիսկ ավելի հեշտ է. այստեղ մենք արդեն պատրաստ ենք օգտագործելու HasUuids հատկանիշը: Որպես այլընտրանք, շրջանակն առաջարկում է նաև համապատասխան, բայց դեռևս բավականին անհայտ տվյալների տիպի ULID , որը կարող է հետաքրքիր լինել ավելի լավ ընթեռնելիության և տեսակավորելու շնորհիվ:
Դժվարը գոյություն ունեցող տվյալների միգրացիան է: Մոտավորապես կարելի էր այսպես վարվել:
- Բոլոր աղյուսակներին ավելացրեք նոր UUID սյունակներ՝ դատարկ արժեքներով
(յուրաքանչյուրը հիմնված է բոլոր հիմնական և արտաքին բանալիների սյունակների վրա) - Նոր սյունակներում գրեք UUID արժեքները
(աճող առաջնային ստեղներով գումարած թարմացված օտարերկրյա ստեղներով) - Ջնջել բնօրինակ սյունակները
- Վերանվանել նոր սյունակներ
Այստեղ կան մի քանի մարտահրավերներ. միգրացիայի գործընթացը երկար ժամանակ է տևում, և աղյուսակի վերջում կցվում են նոր սյունակներ (հնարավոր լուծում. առողջարանային սյունակներ ): Շատ ավելի անմիջական միջոց է սյունակները ուղղակիորեն փոխակերպել:
Եթե դուք դա դնեք PostgreSQL մեկը, դուք կարող եք (նախկին կրկնօրինակումից հետո, իհարկե) գործարկել հետևյալ հարցումը, օրինակ (մինչ այդ կարող եք ջնջել բոլոր աղյուսակները, որոնք բացառել եք Z-ում։ 19/31 փոխարինել, ինչպես նաև սեփական հատուկ կանոններ Զ. 37/39 ավելացնել) և պատճենում է դրանից առաջացած բոլոր հարցումները:
2aa7136d977617159be1834eaf40e871
Եթե դուք այժմ գործարկում եք ստեղծված հարցումները միասին, ապա կարճ ժամանակում դուք տեղափոխել եք տվյալների բազան: Թեև այսպիսով ստեղծվող UUID-ները չեն համապատասխանում v4 բնութագրին, դրանք բառագրական առումով նույն հաջորդականությամբ են, ինչ նախորդ գրառումները, չեն բախվում նոր UUID-ներին (v4-ի 3-րդ խմբում միշտ կա 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