यूयूआईडी (यूनिवर्सली यूनिक आईडी एंटिफायर) 128-बिट मान हैं जो डेटाबेस में उपयोग किए जाते हैं, अन्य बातों के अलावा, तालिका प्रविष्टियों को विशिष्ट रूप से पहचानने के लिए। उन्हें हाइफ़न द्वारा अलग किए गए पांच समूहों में विभाजित हेक्साडेसिमल स्ट्रिंग के रूप में दर्शाया जाता है (उदाहरण: 09fe49b3-4d2b-471c-ac04-36c9e706b85f) वहाँ है बहुत चर्चाएँ डेटाबेस में यूयूआईडी के फायदे और नुकसान के बारे में - वे वितरित सिस्टम में अपरिहार्य हैं।
माइक्रोसर्विसेज और बहु-किरायेदारी अनुप्रयोगों में, इसलिए यूयूआईडी शुरू करने पर विचार करना उचित है। PHP फ्रेमवर्क में डेटा प्रकार BigInteger से UUID ( RFC 4122 विनिर्देशन से UUID संस्करण 4 का एक क्रमबद्ध संस्करण) पर स्विच करना जल्दी से किया जाता है: सबसे पहले, हम एक नई विशेषता बनाते हैं:
2aa7136d977617159be1834eaf40e871
फिर हम अपने सभी मॉडल जोड़ते हैं:
2aa7136d977617159be1834eaf40e871
Laravel 9⁺ में यह और भी आसान है: यहाँ हमारे पास पहले से ही HasUuids विशेषता उपयोग के लिए तैयार है। वैकल्पिक रूप से, फ्रेमवर्क संबंधित, लेकिन फिर भी अज्ञात डेटा प्रकार ULID के लिए समर्थन प्रदान करता है, जो बेहतर पठनीयता और क्रमबद्धता के कारण दिलचस्प हो सकता है।
मुश्किल हिस्सा मौजूदा डेटा का माइग्रेशन है। मोटे तौर पर कोई इस प्रकार आगे बढ़ सकता है:
- सभी तालिकाओं में खाली मानों के साथ नए यूयूआईडी कॉलम जोड़ें
(प्रत्येक सभी प्राथमिक और विदेशी कुंजी स्तंभों पर आधारित) - नए कॉलम में UUID मान लिखें
(आरोही प्राथमिक कुंजी और अद्यतन विदेशी कुंजी के साथ) - मूल कॉलम हटाएं
- नए कॉलम का नाम बदलें
यहां कई चुनौतियां हैं: माइग्रेशन प्रक्रिया में लंबा समय लगता है और तालिका के अंत में नए कॉलम जोड़े जाते हैं (संभावित समाधान: रिसॉर्ट कॉलम )। कॉलम को सीधे बदलने का एक और सीधा तरीका है।
अगर आप इसे डालते हैं पोस्टग्रेएसक्यूएल एक, आप (पिछले बैकअप के बाद, निश्चित रूप से) निम्न क्वेरी चला सकते हैं, उदाहरण के लिए (इससे पहले आप उन सभी तालिकाओं को हटा सकते हैं जिन्हें आप Z में शामिल नहीं करते हैं। 19/31 प्रतिस्थापित करें, साथ ही Z में स्वयं के विशेष नियम। 37/39 जोड़ें) और इससे उत्पन्न सभी प्रश्नों की प्रतिलिपि बनाता है:
2aa7136d977617159be1834eaf40e871
यदि आप अब जनरेट की गई क्वेरीज़ को एक साथ चलाते हैं, तो आपने थोड़े समय के भीतर डेटाबेस को माइग्रेट कर दिया है। जबकि इस प्रकार उत्पन्न UUIDs v4 विनिर्देश के अनुरूप नहीं हैं, वे पिछली प्रविष्टियों के समान क्रम में हैं, नए UUIDs से नहीं टकराते हैं (v4 में तीसरे समूह में हमेशा एक होता है 4, माइग्रेट किए गए संस्करण में हमेशा एक 0), जिसका अर्थ यह भी है कि नए यूयूआईडी हमेशा माइग्रेट किए गए यूयूआईडी से बड़े होते हैं।
उसके बाद सभी लारवेल कैश को हटाने की सिफारिश की जाती है (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/*) खाली करना। बेशक, पूरी बात को लारवेल प्रवास के भीतर भी लागू किया जा सकता है:
2aa7136d977617159be1834eaf40e871
रूपांतरण के बाद भविष्य में होने वाले माइग्रेशन में इसका उपयोग किया जाता है bigIncrements या। bigInteger फिर uuid:
2aa7136d977617159be1834eaf40e871