सवाल अनोखी कुंजी बनाम प्राथमिक कुंजी?


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

मैंने कई लेख / चर्चा / समाचार समूह पदों को पढ़ते हुए कहा कि पीके के बजाय अद्वितीय बाधा (कुछ डीबी के लिए उर्फ ​​अद्वितीय सूचकांक) का उपयोग करना बेहतर है।

आपका दृष्टिकोण क्या है?


44
2017-10-01 16:10


मूल




जवाब:


क्या आप इन लेखों के संदर्भ प्रदान कर सकते हैं?

मुझे कोशिश की गई और सही विधियों को बदलने का कोई कारण नहीं दिखता है। आखिरकार, प्राथमिक कुंजी संबंधपरक डेटाबेस की एक मौलिक डिजाइन सुविधा है।

एक ही उद्देश्य की सेवा के लिए अद्वितीय का उपयोग करना वास्तव में मुझे हैकिश लगता है। उनका तर्क क्या है?

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


38
2017-10-01 16:55



आप कहते हैं कि यह एक कुंजी है, अगर यह अद्वितीय है, तो इसे एक कुंजी बनाएं, इसे अद्वितीय बनाएं। लेकिन वास्तव में, क्या एक कुंजी एक कुंजी बनाता है और अद्वितीय नहीं है? ए की आपकी परिभाषा क्या है कुंजी? - Pacerier
@Pacerier मान लीजिए कि हमारे पास छात्र सूचना डेटाबेस है। इस डेटाबेस में, छात्रों को प्राथमिक कुंजी छात्र संख्या के साथ पहचाना जाता है। छात्रों की मेज में, हम एसएसएन / एसआईएन या अन्य क्षेत्रीय समकक्ष जैसी चीजें रखते हैं। कुंजी त्रुटि त्रुटि जांच के हिस्से के रूप में, हम चाहते हैं कि यह फ़ील्ड अद्वितीय हो। लेकिन यह एक महत्वपूर्ण क्षेत्र नहीं है। (हालांकि यह हो सकता है, स्टूइड और एसएसएन के बीच 1: 1 पत्राचार मानते हुए) कक्ष असाइनमेंट भी अद्वितीय हो सकता है, लेकिन कुंजी नहीं। (हालांकि मैं छात्र के लिए कमरे के मुकाबले एक कमरे में एक छात्र को आवंटित करने के इच्छुक हूं) - Chris Cudmore
आपके उदाहरण में, एसएसएन / एसआईएन कुंजी क्यों नहीं बनाते? - Pacerier
छात्र आईडी प्रत्येक असाइनमेंट, और विश्वविद्यालय और छात्र के बीच पत्राचार के हर टुकड़े पर लिखे गए हैं। क्या आप वास्तव में चाहते हैं कि आपका एसएसएन इतना घबराहट से घिरा हुआ हो? एक परिपूर्ण दुनिया में, आप सही हैं। एक सार्वभौमिक व्यक्ति आईडी जिसका उपयोग सबकुछ के लिए किया जा सकता है। वास्तविक दुनिया में, संस्थान लोगों की पहचानकर्ताओं के रूप में अपनी संख्याएं आवंटित करते हैं, और अन्य उम्मीदवार कुंजी को फ़ाइल पर रखते हैं। - Chris Cudmore
आपने सवाल का समाधान नहीं किया ... छात्र आईडी प्राथमिक कुंजी क्यों नहीं बनाते? क्या आप कह रहे हैं कि छात्र आईडी जा रही है परिवर्तन? - Pacerier


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

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

साथ चलने के लिए महत्वपूर्ण बात यह है कि आपको अनन्य बाधाएं होनी चाहिए सब उम्मीदवार (चाहे प्राकृतिक या सरोगेट) कुंजी। तब आपको उस व्यक्ति को चुनना चाहिए जो संदर्भ में सबसे आसान है विदेशी कुंजी अपनी प्राथमिक कुंजी होने के लिए *।

आपके पास भी होना चाहिए क्लस्टर सूचकांक*। इस सकता है अपनी प्राथमिक कुंजी, या एक प्राकृतिक कुंजी हो - लेकिन यह या तो होने की आवश्यकता नहीं है। आपको तालिका के क्वेरी उपयोग के आधार पर अपना क्लस्टर सूचकांक चुनना चाहिए। संदेह में, प्राथमिक कुंजी खराब पहली पसंद नहीं है।

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

  • संपादित करें: यह इंगित किया गया है कि ओरेकल की "क्लस्टर टेबल" और "क्लस्टरर्ड इंडेक्स" की अवधि एसक्यूएल सर्वर से अलग है। ओरेकल-एज़ में जो मैं बोल रहा हूं उसके बराबर है सूचकांक आदेशित तालिका और OLTP तालिकाओं के लिए इसकी अनुशंसा की जाती है - जो मुझे लगता है, SO प्रश्नों का मुख्य केंद्र होगा। मुझे लगता है कि यदि आप एक बड़े ओलाप डेटा वेयरहाउस के लिए ज़िम्मेदार हैं, तो आपके पास डेटाबेस डिज़ाइन और ऑप्टिमाइज़ेशन पर पहले से ही आपकी राय होनी चाहिए।


46
2017-10-01 16:19



ओरेकल प्रत्येक तालिका पर क्लस्टर्ड इंडेक्स की सिफारिश नहीं करेगा।
क्षमा करें - मैं एक एमएसएसएलएल लड़का हूं, इसलिए मैं ओरेकल शब्दों में ज्यादा नहीं सोचता। मेरी समझ यह है कि ओरेकल क्लस्टर्ड टेबल और इंडेक्स के पास SQL ​​सर्वर क्लस्टर इंडेक्स के साथ कुछ भी नहीं है। ओरेकल समकक्ष एक सूचकांक आदेश तालिका है, जिसे कम से कम OLTP तालिकाओं के लिए अनुशंसित किया जाता है। - Mark Brackett


प्राथमिक कुंजी केवल एक उम्मीदवार कुंजी (अद्वितीय बाधा) विशेष उपचार के लिए एकल (इंडेक्स के स्वचालित निर्माण, आदि) के लिए एकल है।

मैं उम्मीद करता हूं कि जो लोग उनके खिलाफ बहस करते हैं, वे एक कुंजी को दूसरे से अलग तरीके से इलाज करने का कोई कारण नहीं देखते हैं। यही वह जगह है जहां मैं खड़ा हूं।

[संपादित करें] स्पष्ट रूप से मैं 50 अंकों के बिना अपने उत्तर पर भी टिप्पणी नहीं कर सकता।

@ क्रिस: मुझे नहीं लगता कि कोई नुकसान है। "प्राथमिक कुंजी" वास्तव में सिर्फ वाक्य रचनात्मक चीनी है। मैं उन्हें हर समय उपयोग करता हूं, लेकिन मुझे निश्चित रूप से नहीं लगता कि वे आवश्यक हैं। अनोखा कुंजी आवश्यक है, हाँ, लेकिन जरूरी नहीं कि एक प्राथमिक कुंजी।


10
2017-10-01 16:16



तर्क के लिए धन्यवाद। लेकिन नुकसान क्या है? क्या प्रतिमान को परेशान करने के लिए औचित्य है? - Chris Cudmore
> इंडेक्स का स्वचालित निर्माण, आदि सभी डेटाबेस स्वचालित रूप से पीके के लिए एक सूचकांक नहीं बनाते हैं। ओरेकल, एक के लिए, केवल एक मौजूदा सूचकांक का उपयोग कर सकते हैं।


यह बहुत दुर्लभ denormalization होगा जो आपको प्राथमिक कुंजी के बिना एक टेबल बनाना चाहते हैं। प्राथमिक कुंजीों में पीके के रूप में अपनी प्रकृति द्वारा स्वचालित रूप से अद्वितीय बाधाएं होती हैं।

जब आप प्राथमिक कुंजी में अतिरिक्त में कॉलम में विशिष्टता की गारंटी देना चाहते हैं तो एक अनूठी बाधा का उपयोग किया जाएगा।

हमेशा एक पीके के नियम एक अच्छा है।

http://msdn.microsoft.com/en-us/library/ms191166.aspx


9
2017-10-01 19:20





तुम्हे करना चाहिए हमेशा एक प्राथमिक कुंजी है।

हालांकि मुझे संदेह है कि आपका प्रश्न सिर्फ थोड़ा भ्रामक शब्द है, और आप वास्तव में यह पूछना चाहते हैं कि प्राथमिक कुंजी हमेशा स्वचालित रूप से जेनरेट की गई संख्या (सरोगेट कुंजी के रूप में भी जाना जाता है), या कुछ अद्वितीय क्षेत्र जो वास्तविक अर्थपूर्ण डेटा है (जिसे प्राकृतिक भी कहा जाता है) कुंजी), लोगों के लिए एसएसएन, किताबों के लिए आईएसबीएन आदि।

यह सवाल डीबी क्षेत्र में एक पुराना धार्मिक युद्ध है।

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


5
2017-10-01 16:17



सहमत हैं, उदाहरण के लिए एसएसएन अक्सर डेटा प्रविष्टि त्रुटियों के रूप में बदल जाता है और जब लोग पहचान चोरी जैसी चीजों के कारण एक नया प्राप्त करते हैं। - HLGEM
मेरा सवाल यह नहीं है कि आपका क्या मतलब है। यह वास्तव में एक अनन्य कुंजी बनाम एक प्राथमिक कुंजी का उपयोग कर रहा है। - vIceBerg
ठीक है। फिर जवाब है: आपको हमेशा प्राथमिक कुंजी रखना चाहिए। मुझे लगता है कि जो लोग आपको सलाह देते हैं वे अन्यथा उलझन में हैं, ध्यान दें कि एक पीके हमेशा एक अद्वितीय कुंजी- - JacquesB
मैं वास्तव में इस उत्तर की तलाश में आया, बस यह सुनिश्चित करने के लिए, अगर मेरे डेटाबेस एंट्री में कोई ऐसा क्षेत्र है जो किसी भी परिस्थिति में कभी नहीं बदलेगा, और यह भी अनूठा है, तो इसे प्राथमिक कुंजी अधिकार के रूप में उपयोग करना चाहिए? - Pochi


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

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


3
2017-10-01 18:20



कुछ डीबी के साथ, आप एक अद्वितीय इंडेक्स के क्षेत्र में एक विदेशी कुंजी बना सकते हैं - vIceBerg


जब तक आप उस पर काम करते समय डेटा को चरणबद्ध करने के लिए तालिका एक अस्थायी तालिका नहीं है, तब भी आप तालिका पर प्राथमिक कुंजी रखना चाहते हैं और यहां क्यों है:

1 - एक अनूठी बाधा नल की अनुमति दे सकती है लेकिन एक प्राथमिक कुंजी कभी नहीँ नल की अनुमति देता है। यदि आप शून्य मानों वाले कॉलम पर शामिल होने के साथ कोई क्वेरी चलाते हैं तो आप परिणामी डेटा सेट से उन पंक्तियों को खत्म करते हैं क्योंकि शून्य शून्य के बराबर नहीं है। इस प्रकार बड़ी कंपनियां लेखांकन त्रुटियां भी कर सकती हैं और उन्हें अपने मुनाफे को फिर से भरना पड़ता है। उनके प्रश्नों ने कुछ पंक्तियां नहीं दिखायीं जिन्हें कुल मिलाकर शामिल किया जाना चाहिए क्योंकि उनके अद्वितीय सूचकांक के कुछ स्तंभों में शून्य मान थे। कंधे एक प्राथमिक कुंजी का इस्तेमाल किया।

2 - एक अनन्य इंडेक्स स्वचालित कुंजी पर स्वचालित रूप से रखा जाएगा, इसलिए आपको एक बनाना नहीं है।

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

4 - तालिका को अद्यतन करने या हटाने के लिए कई फ्रंट एंड डेवलपमेंट वातावरणों को प्राथमिक कुंजी की आवश्यकता होती है।


3
2017-10-01 18:51



बिंदु # 4 के लिए +1। दुर्लभ मामले में जहां आप पीके के बिना टेबल बनाना चाहते हैं, मेरे सामने आने वाले सभी जीयूआई पंक्ति संपादन टूल बस काम करना बंद कर देंगे। - Daniel Yankowsky


हमें तार्किक संरचनाओं और शारीरिक संरचनाओं के बीच और समान रूप से सिद्धांत और अभ्यास के बीच एक भेद करने की आवश्यकता है।

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

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

इसके अलावा, कुछ आरडीबीएमएस अतिरिक्त विशेषताएं उपलब्ध कराते हैं यदि प्राथमिक कुंजी ठीक से लेबल किए जाते हैं, जैसे आरेखण, और अर्द्ध स्वचालित विदेशी-कुंजी-बाधा समर्थन।

कोई भी जो आपको सामान्य नियमों के बजाय प्राथमिक कुंजी के बजाय अनोखी बाधाओं का उपयोग करने के लिए कहता है, उसे एक सुंदर शापित अच्छा कारण प्रदान करना चाहिए।


2
2017-10-01 16:18





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

व्यक्तिगत रूप से, मैं अपने टेबल के बीच क्रॉस रेफरेंसिंग के लिए उपयोग की जाने वाली अद्वितीय कुंजी के लिए या तो GUID या ऑटो-वृद्धिशील बिगिनट्स (एसक्यूएल सर्वर के लिए पहचान सम्मिलित) का उपयोग करता हूं। फिर मैं उपयोगकर्ता को विशिष्ट रिकॉर्ड चुनने की अनुमति देने के लिए अन्य डेटा का उपयोग करूंगा।

उदाहरण के लिए, मेरे पास कर्मचारियों की एक सूची होगी, और मेरे पास दृश्यों के पीछे उपयोग किए जाने वाले प्रत्येक रिकॉर्ड से एक GUID संलग्न होगा, लेकिन जब उपयोगकर्ता किसी कर्मचारी का चयन करता है, तो वे उन्हें निम्न फ़ील्ड के आधार पर चुन रहे हैं: LastName + FirstName + कर्मचारी संख्या।

इस परिदृश्य में मेरी प्राथमिक कुंजी LastName + FirstName + EmployeeNumber है जबकि अनन्य कुंजी संबद्ध GUID है।


1
2017-10-01 19:02



इस तरह मैं इसे भी करता हूं: प्राथमिक कुंजी के रूप में 'निजी' आईडी (आमतौर पर BIGINT) का उपयोग करें। सामान्यीकरण उद्देश्यों के लिए मैं स्रोत या ट्रिगर्स के रूप में नियमों को लागू करता हूं। मुझे दृढ़ विश्वास है कि डेटाबेस को सभी डेटा कैप्चर करना चाहिए, और डेटा का हेरफेर कहीं और किया जाता है। - slashmais


पोस्ट कह रही है कि पीके के बजाय अद्वितीय बाधा (कुछ डीबी के लिए उर्फ ​​अद्वितीय सूचकांक) का उपयोग करना बेहतर है

मुझे लगता है कि यहां एकमात्र बिंदु वही पुरानी चर्चा "प्राकृतिक बनाम सरोगेट कुंजी" है, क्योंकि अद्वितीय इंडेक्स और पीके एक ही चीज हैं।

अनुवाद:

पोस्ट कह रही है कि सरोगेट कुंजी के बजाय प्राकृतिक कुंजी का उपयोग करना बेहतर है


1
2017-10-02 01:25





मैं आमतौर पर पीके और अद्वितीय कुंजी दोनों का उपयोग करता हूं। क्योंकि यदि आप अपनी स्कीमा में पीके को इंगित नहीं करते हैं, तो हमेशा आपके लिए आंतरिक रूप से उत्पन्न होता है। यह SQL सर्वर 2005 और MySQL 5 दोनों के लिए सच है।

लेकिन मैं अपने एसक्यूएल में पीके कॉलम का उपयोग नहीं करता हूं। यह प्रबंधन उद्देश्यों के लिए है जैसे कुछ ग़लत पंक्तियों को हटाने, पीके मूल्यों के बीच अंतराल को खोजने के लिए यदि यह ऑटो वृद्धि पर सेट है। और, यह पीके को संख्याओं के रूप में, कॉलम या चार सरणी के सेट के रूप में समझ में आता है।


1
2017-10-02 10:02



कुछ यादृच्छिक और मूर्खतापूर्ण downvote का मुकाबला करने के लिए upvoted - Steven A. Lowe