v4 लें या v7
v4 के 122 बिट पूरी तरह यादृच्छिक होते हैं। मान देखकर यह पता नहीं चलता कि वह कब या कहाँ बना। सार्वजनिक URL में दिखने वाले पहचानकर्ता, न्योते के लिंक — जहाँ बनने का क्रम छिपा रहना चाहिए, वहाँ यही ठीक है।
v7 में पहले 48 बिट मिलीसेकंड का टाइमस्टैम्प होते हैं और बाकी यादृच्छिक, इसलिए स्ट्रिंग को क्रम में लगाना ही बनने के क्रम में लगाना है। डेटाबेस की प्राइमरी की, लॉग के पहचानकर्ता, इवेंट आईडी — जहाँ समय का क्रम काम आता है, वहाँ इसे लें। बदले में बनने का समय मान से ही पढ़ा जा सकता है; अगर वह बात छिपानी हो तो v4 पर लौट आएँ।
NIL पूरे शून्य वाला खास मान है। जिस कॉलम में NULL नहीं चलता, वहाँ “अभी कुछ नहीं” रखने के लिए इसे प्लेसहोल्डर की तरह इस्तेमाल करते हैं।
डेटाबेस की प्राइमरी की के रूप में
अपने आप बढ़ने वाले पूर्णांक की जगह UUID रखने पर कई सर्वर आपस में पूछे बिना की बना सकते हैं, और URL में आईडी दिखने पर भी पड़ोसी पंक्तियाँ अंदाज़ से नहीं निकाली जा सकतीं।
अड़चन v4 की यादृच्छिकता है। B-tree इंडेक्स तब सबसे अच्छा चलता है जब नई की आखिर में जुड़े, पर v4 हर बार इंडेक्स के बीच कहीं भी घुसती है और पेज बार-बार बँटते रहते हैं। टेबल जितनी बड़ी होगी, लिखना उतना धीमा और इंडेक्स उतना भारी। v7 में मान समय के साथ बढ़ते हैं और नई की हमेशा आखिर में लगती है, इसलिए यह दिक्कत नहीं आती। नई टेबल के लिए v7 समझदारी भरा डिफ़ॉल्ट है।
MySQL में BINARY(16) और PostgreSQL में uuid टाइप में रखें। 36 अक्षर की स्ट्रिंग रखने पर हर पंक्ति में 20 बाइट ज़्यादा लगते हैं और हर तुलना धीमी होती है।
बिना हाइफ़न वाला रूप
हाइफ़न दिखाने का तरीका है, मान का हिस्सा नहीं। फ़ाइल नाम, कूपन कोड और कुछ API में 32 अक्षर वाला जुड़ा रूप चलता है। बड़े अक्षर भी सिर्फ़ प्रस्तुति हैं — दो UUID मिलाने से पहले दोनों को छोटे अक्षरों में कर लेना सुरक्षित रहता है।
एक साथ कई बनाते समय
यह टूल एक साथ कई v7 बनाते समय बनने का क्रम बनाए रखता है। एक ही मिलीसेकंड में बने मानों का टाइमस्टैम्प एक जैसा होता है और क्रम बिखर जाता, इसलिए यादृच्छिक हिस्से का एक टुकड़ा गिनती के लिए इस्तेमाल होता है। पूरी सूची जस की तस कॉपी कर लें, क्रम बना रहेगा।