मैंने अपने पेशेवर जीवन में इसी समस्या का सामना किया है। हमने टाइमस्टैम्प + रैंडम नंबर का इस्तेमाल किया और जब हमारे एप्लिकेशन बड़े हुए (अधिक क्लाइंट, अधिक सर्वर, अधिक अनुरोध) तो गंभीर मुद्दों का सामना करना पड़ा। माना, हमने (बेवकूफ) केवल 4 अंकों का उपयोग किया, और फिर 6 में बदल दिया, लेकिन आपको आश्चर्य होगा कि त्रुटियां कितनी बार होती हैं।
काफी लंबे समय से, आपको गारंटीकृत . है डुप्लिकेट कुंजी त्रुटियां प्राप्त करने के लिए। हमारा आवेदन मिशन महत्वपूर्ण है, और इसलिए स्वाभाविक रूप से यादृच्छिक व्यवहार के कारण असफल होने का सबसे छोटा मौका भी अस्वीकार्य था। हमने इस समस्या से बचने के लिए यूयूआईडी का उपयोग करना शुरू किया, और सावधानीपूर्वक उनके निर्माण का प्रबंधन किया।
यूयूआईडी का उपयोग करने से, आपके सूचकांक का आकार बढ़ जाएगा, और एक बड़े सूचकांक के परिणामस्वरूप खराब प्रदर्शन होगा (शायद ध्यान देने योग्य नहीं, लेकिन कम-से-कम खराब)। हालाँकि MySQL एक देशी UUID प्रकार का समर्थन करता है (प्राथमिक कुंजी के रूप में कभी भी varchar का उपयोग न करें !!), और बड़े पैमाने की तुलना में अनुक्रमण, खोज, आदि को बहुत कुशलता से संभाल सकता है। आपकी अनुक्रमणिका पर सबसे बड़ा प्रदर्शन लगभग हमेशा अनुक्रमित पंक्तियों की संख्या है, न कि आइटम का आकार अनुक्रमणिका (जब तक कि आप किसी लंबे टेक्स्ट या उस तरह की हास्यास्पद चीज़ पर अनुक्रमणित नहीं करना चाहते)।
आपके प्रश्न का उत्तर देने के लिए:यदि आप अपने आवेदन/सेवा को महत्वपूर्ण रूप से बढ़ाने की योजना नहीं बनाते हैं तो बिगिंट (यादृच्छिक संख्याओं के साथ संलग्न) ठीक रहेगा। यदि आपका कोड बिना किसी बदलाव के परिवर्तन को संभाल सकता है और डुप्लिकेट कुंजी त्रुटि होने पर आपका एप्लिकेशन विस्फोट नहीं करेगा, तो इसके साथ जाएं। अन्यथा, गोली मारो और अधिक महत्वपूर्ण विकल्प के लिए जाओ।
आप बाद में कभी भी बड़ा बदलाव लागू कर सकते हैं, जैसे किसी पूरी तरह से अलग बैकएंड पर स्विच करना (जिसका अब हम सामना कर रहे हैं... :P)
