डेटाबेस प्राथमिक कुंजी के लिए UUIDs, autoincrement/अनुक्रम कुंजी और अनुक्रम तालिकाओं के बीच कैसे चयन करें?

Question

मैं डेटाबेस पंक्तियों के लिए प्राथमिक कुंजी के साथ आने के इन तीन प्राथमिक तरीकों के पेशेवरों और विपक्ष को देख रहा हूं।

तो मान लीजिए कि मैं एक ऐसे डेटाबेस का उपयोग कर रहा हूं जो इन तरीकों में से एक से अधिक का समर्थन करता है, यह निर्धारित करने के लिए एक सरल ह्युरिस्टिक है कि मेरे लिए सबसे अच्छा विकल्प क्या होगा?

ऐसे वितरित/एकाधिक स्वामी, प्रदर्शन आवश्यकताओं, ओआरएम उपयोग, सुरक्षा और परीक्षण के विचारों पर विचार कैसे किया जाता है?

कोई भी अप्रत्याशित कमी जो कोई भी हो सकती है?

Answer 1

UUIDs

जब तक इन उत्पन्न कर रहे हैं वे काफी चोट पहुंचा सकते हैं/टुकड़ा अनुक्रमणिका "monotonic अनुक्रम बढ़ाने में"। यूयूआईडी पीढ़ी के लिए समर्थन सिस्टम द्वारा भिन्न होता है। उपयोग करने योग्य होने पर, मैं ज्यादातर मामलों में यूयूआईडी का उपयोग अपने प्राथमिक क्लस्टर इंडेक्स/पीके के रूप में नहीं करता। यदि आवश्यक हो तो मैं इसे एक माध्यमिक कॉलम बना सकता हूं, शायद अनुक्रमित, शायद नहीं।

कुछ लोग तर्क देते हैं कि यूयूआईडी का उपयोग मनमाने ढंग से सिस्टम की संख्या से सुरक्षित रूप से उत्पन्न/विलय करने के लिए किया जा सकता है। जबकि एक यूयूआईडी (विधि के आधार पर) आम तौर पर टकराव का खगोलीय रूप से छोटा मौका होता है, कम से कम कुछ बाहरी इनपुट या बहुत दुर्भाग्य के साथ संभव है :) - टकराव उत्पन्न करें। मुझे विश्वास है कि केवल सच पीके सिस्टम के बीच प्रसारित किया जाना चाहिए, जो कि मैं तर्क दूंगा कि डेटाबेस-जेनरेट अधिकांश मामलों में यूयूआईडी नहीं है।

autoincrement/अनुक्रम कुंजी और अनुक्रम टेबल

यह वास्तव में क्या डेटाबेस में अच्छी तरह से समर्थन करता है पर निर्भर करता है। कुछ डेटाबेस अनुक्रमों का समर्थन करते हैं जो अधिक सरल होते हैं जो एक सरल "ऑटो-वृद्धि" होते हैं। यह वांछित हो सकता है या नहीं हो सकता है (या इस तरह के कार्य के लिए भी एकमात्र तरीका हो सकता है)। अनुक्रम तालिकाएं आम तौर पर अधिक लचीली होती हैं, लेकिन अगर इस तरह की "लचीलापन" की आवश्यकता होती है तो मुझे वापस जाने और डिजाइन-पैटर्न पर जाने का लुत्फ उठाना होगा, खासकर यदि इसमें ट्रिगर्स का उपयोग शामिल है। जबकि मैं "सीमित ओआरएम" नापसंद करता हूं, इससे "सरल" ऑटो-वृद्धि या अनुक्रम प्रकार/डेटाबेस समर्थन चुनने में भी अंतर हो सकता है।

विधि के बावजूद, इस्तेमाल किया जब किराए की प्राथमिक कुंजी का उपयोग कर, सच प्राथमिक कुंजी अभी भी पहचान की है और स्कीमा में एन्कोड किया जाना चाहिए।

इसके अलावा, मैं तर्क देता हूं कि "ऑटो-अनुक्रम पीके को उजागर करने से सुरक्षा समझौता" आंतरिक डेटाबेस संपत्ति को गलत तरीके से उजागर करने का परिणाम है। सीआरयूडी ऑपरेशन को संभालने का एक बहुत ही आसान तरीका है, मेरा मानना ​​है कि आंतरिक कुंजी और उजागर कुंजी (उदा। सुंदर ग्राहक संख्या) के बीच एक अंतर है।

बस मेरे दो सेंट।

संपादित, टिम करने के लिए अतिरिक्त उत्तर:

मुझे लगता है कि उत्पन्न बनाम सच पी सवाल एक बहुत अच्छा एक और एक मैं भी विचार करने की जरूरत है। मैं सामान्य रूप से आपके द्वारा बनाए गए बिंदुओं पर यूयूआईडी चाहता हूं। मेरा हिचकिचाहट आकार बनाम एक int/long था। संभावित इंडेक्सिंग डी-ऑप्टिमाइज़ेशन से अवगत नहीं था, जो मेरे लिए बहुत बड़ी चिंता है।

मैं वास्तव में आकार के बारे में चिंता नहीं करता है - अगर एक UUID सबसे अच्छा है, तो यह सबसे अच्छा है। यदि यह नहीं है, तो यह नहीं है। समग्र योजना में एक अतिरिक्त संभावना से अधिक 12bytes अधिक अंतर नहीं उठाएंगे। सामान्य यूयूआईडी पीढ़ी से जुड़े विखंडन से बचने के लिए SQL Server 2005+ newsequentialid UUID पीढ़ी फ़ंक्शन का समर्थन करता है। पृष्ठ कुछ पर चर्चा करता है। मुझे यकीन है कि अन्य डेटाबेस में समान समाधान हैं।

और से, आप एक विशिष्टता बाधा जोड़ने से अधिक मतलब है "स्कीमा में इनकोडिंग"?

हां। प्राथमिक कुंजी केवल [अद्वितीय] बाधा नहीं है। बस एक किराए पी का उपयोग कर डेटाबेस मॉडल मतलब यह नहीं है :-) अतिरिक्त अनुक्रमित समझौता किया जाना चाहिए भी कवर करने के लिए इस्तेमाल किया जा सकता आदि

और "के बीच अंतर" करके, आप कह रहे हैं कि किराए की प्राथमिक कुंजी कभी रिसाव नहीं?

मेरी आरंभिक पोस्ट में शब्दों एक बालक मुश्किल था। यह "कभी नहीं" इतना है "अगर वे करते हैं और यह मायने रखता है तो यह एक और समस्या है"। अक्सर लोग अनुमानित संख्याओं के माध्यम से असुरक्षा की शिकायत करते हैं - उदा। यदि आपका ऑर्डर 23 है तो ऑर्डर 22 और 24 ऑर्डर हो सकता है। यदि यह आपकी "सुरक्षा" है और/या संवेदनशील जानकारी को रिसाव कर सकता है तो सिस्टम पहले से ही त्रुटिपूर्ण है। (आंतरिक और बाहरी आईडी को अलग करना इस समस्या को निहित रूप से ठीक नहीं करता है और प्रमाणीकरण/प्रमाणीकरण अभी भी आवश्यक है। हालांकि, "अनुक्रमिक आईडी" का उपयोग करने के खिलाफ यह एक मुद्दा उठाया गया है - मुझे लगता है कि वितरित यूआरएल में एक गैर-एन्कोडिंग को मेरे उपयोग के लिए को संभालता है -case बल्कि अच्छी तरह से)

क्या मैं वास्तव में भर में प्राप्त करना चाहता था को अधिक:। सिर्फ इसलिए कि सरोगेट पी आईडी होने के लिए 8942 का मतलब यह नहीं है कि यह आदेश 8942. यही है, "कुछ क्षेत्रों के अनुरूप है होता है केवल डीबी "डिजाइन, ऑर्डर" नंबर के लिए आंतरिक हैं, सतह पर पूरी तरह से असंबंधित हो सकते हैं (लेकिन डीबी मॉडल में पूरी तरह से समर्थित), जैसे कि "# 2010-42 सी" या जो भी व्यवसाय की आवश्यकता के लिए समझ में आता है। यह बाहरी संख्या है जो अधिकांश मामलों में सामने आना चाहिए।

मुझे लगता है कि कभी कभी उत्पन्न कुंजी वास्तव में सच प्राथमिक कुंजी के रूप में अन्य क्षेत्रों परिवर्तनशील हैं (जैसे। उपयोगकर्ता ईमेल और उपयोगकर्ता नाम बदल सकते हैं)।

इस मामले एक डेटाबेस के भीतर हो सकता है और मैं इस बयान बहस नहीं होगी। हालांकि, एक बार फिर यह मानते हुए कि सरोगेट पीके डेटाबेस में आंतरिक हैं, बस सुनिश्चित करें कि केवल उन tuples को निर्यात/आयात करें जिन्हें अच्छी तरह पहचाना जा सके। यदि उपयोगकर्ता नाम/ईमेल बदल सकता है, तो यह खाता निर्माण पर असाइन किए गए यूयूआईडी को बहुत अच्छी तरह से शामिल कर सकता है - और सरोगेट पीके स्वयं भी बहुत अच्छा हो सकता है।

बेशक, सबकुछ के साथ, समस्या के लिए मॉडल खुले रहें और मॉडल के लिए समस्या न करें :-) ट्विटर जैसी सेवा के लिए, उदाहरण के लिए, वे अपनी संख्या पीढ़ी स्कीमा का उपयोग करते हैं। Twitter's new ID generation देखें। [कुछ] यूयूआईडी पीढ़ी के विपरीत, ट्विटर द्वारा दृष्टिकोण (यह मानते हुए कि सभी सर्वर सही तरीके से सेटअप हैं) की गारंटी देता है कि वितरित मशीनों/प्रक्रियाओं में से कोई भी कभी भी डुप्लिकेट आईडी उत्पन्न नहीं करेगा, केवल 64-बिट्स की आवश्यकता होती है, और किसी न किसी ऑर्डरिंग को बनाए रखती है (सबसे महत्वपूर्ण बिट्स समय-टिकट हैं)। (ट्विटर द्वारा उत्पन्न रिकॉर्ड्स की संख्या स्थानीय आवश्यकताओं से संबंधित नहीं हो सकती है ;-)

हैप्पी कोडिंग।