UUID v7 जेनरेटर

सालों तक, जो इंजीनियरिंग टीमें किसी UUID की टकराव-रोधी क्षमता चाहती थीं लेकिन साथ में किसी क्रमबद्ध इंटीजर का इंडेक्स-अनुकूल क्रम भी, उन्हें अपना ख़ुद का ग़ैर-स्टैंडर्ड हाइब्रिड बनाना पड़ता था — आमतौर पर किसी रैंडम UUID के आगे हाथ से जेनरेट किया टाइमस्टैंप लगाकर, एक तरीक़ा जो कई जाने-माने डिस्ट्रिब्यूटेड सिस्टम कंपनियों ने इसके लिए किसी आधिकारिक स्टैंडर्ड के मौजूद होने से पहले अलग-अलग रूपों में इस्तेमाल किया। RFC 9562 ने उस पैटर्न को एक आधिकारिक UUID वर्ज़न में औपचारिक बनाया ख़ास तौर पर ताकि अलग-अलग भाषाओं और डेटाबेस में इम्प्लीमेंटेशन बिना हर टीम को उसी विचार का थोड़ा अलग और असंगत वैरिएंट स्वतंत्र रूप से दोबारा बनाए एक जैसी समय-क्रमबद्ध संरचना बना और पहचान सकें।

किसी UUID v7 के शुरुआती 48 बिट मिलीसेकंड में Unix टाइमस्टैंप एनकोड करते हैं, जो वैल्यू को उसका क्रमबद्धता क्रम देता है — दो UUID v7 की सादी स्ट्रिंग के रूप में तुलना करना सही तरीक़े से दर्शाती है कि कौन सा पहले जेनरेट हुआ, क्योंकि टाइमस्टैंप हिस्सा तुलना पर हावी रहता है। बाक़ी बिट क्रिप्टोग्राफ़िक रूप से रैंडम डेटा से भरे रहते हैं, बिल्कुल v4 की तरह, तो वैल्यू पूरी तरह रैंडम UUID जितनी ही अनुमान लगाने में नामुमकिन है; सिर्फ़ इसका क्रमबद्धता व्यवहार बदलता है, इसकी अप्रत्याशितता नहीं।

कच्ची इंसर्शन स्पीड से आगे, किसी समय-क्रमबद्ध प्राइमरी की का एक दूसरा व्यावहारिक फ़ायदा है जो रोज़ मायने रखता है: पंक्तियाँ किसी सादी `ORDER BY id` क्वेरी से स्वाभाविक रूप से बनने के क्रम में वापस आती हैं, बिना सिर्फ़ रिकॉर्ड को कालक्रम से क्रमबद्ध करने के लिए एक अलग `created_at` कॉलम और उस पर एक अतिरिक्त इंडेक्स चाहे। किसी ऐसी टेबल के लिए जो अक्सर "सबसे हाल का पहले" क्वेरी की जाती है — कोई एक्टिविटी लॉग, कोई क्यू, कोई ऑडिट ट्रेल — कोई v7 प्राइमरी की वह क्रमबद्धता मुफ़्त में देती है, ख़ुद ID का एक साइड इफ़ेक्ट के रूप में, बनाए रखने के लिए किसी अलग क़ीमत की बजाय।