आपको अपनी प्राथमिक कुंजी कैसे पसंद है? [बन्द है]

Question

मेरी टीम में एक काफी एनिमेटेड चर्चा में मुझे यह सोचने के लिए बनाया गया था कि ज्यादातर लोगों को प्राथमिक कुंजी के रूप में क्या पसंद है। हमारे पास निम्नलिखित समूह थे-

1. इंट / बिगआईंट जो कि ऑटोइंक्रिमेंट पर्याप्त प्राथमिक कुंजी हैं।
2. कम से कम 3 कॉलम होने चाहिए जो प्राथमिक कुंजी बनाते हैं।
3. आईडी, GUID और मानव पठनीय पंक्ति पहचानकर्ता सभी के साथ अलग व्यवहार किया जाना चाहिए।

पीके के लिए सबसे अच्छा तरीका क्या है? अगर आप अपनी राय को सही ठहरा सकते हैं तो यह बहुत बढ़िया होगा। क्या एक बेहतर दृष्टिकोण है जो ऊपर है?

संपादित करें: किसी के पास एक सरल नमूना / एल्गोरिदम है जो पंक्तियों के लिए मानव पठनीय पहचानकर्ताओं को अच्छी तरह से उत्पन्न करता है?

Comments

चूँकि यह व्यक्तिपरक है, यह एक सामुदायिक विकि होना चाहिए

— जॉन शेहान

"प्राथमिक कुंजी बनाने वाले कम से कम 3 कॉलम होने चाहिए"? इसका क्या मतलब है? क्या आप आगे की परिभाषा प्रदान कर सकते हैं? या ये # 3 का हिस्सा है?

— एस.लॉट

@ S.Lott PK(NEWID(),NEWID(),NEWID());-)

@st: यह एक आवश्यकता क्यों है? पीके में तीन कॉलम क्यों होने चाहिए? क्यों एक या चार?

— एस.लॉट

मैं एक तीन कॉलम पीके देख सकता था जैसे ... लोकलिड (ऑटो इंक्रीमेंट इंट), ग्लोबलआईडी (जीयूआईडी), फॉरेनआईडी (रोल्सटाइप जैसी विदेशी कुंजी), आदि। लोकलिड + फोरिएग्निड एक मिश्रित कुंजी संयोजन हो सकता है। गाइड का उपयोग अन्य वेबसाइट / सेवाओं के लिए किया जाता है। व्यक्तिगत रूप से मैं ऐसा नहीं करूंगा, मैं सिर्फ Guide + ForiegnId का उपयोग करूंगा।

— जेरद

Answer 1

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

स्वत: अंकन आपके डिफ़ॉल्ट होना चाहिए, और उनका उपयोग नहीं करना उचित होना चाहिए।

Comments

एक GUID आवश्यक नहीं है, बस चरण 10 या 20 को बदलें या फिर कई सर्वरों को आपको संभवतः भविष्य में सिंक करने की आवश्यकता होगी।

— रॉबर्ट सी। बर्थ

90% समय कम से कम, एक GUID की जरूरत नहीं है और अंतरिक्ष को बर्बाद करता है।

— जोनाथन लेफ्लर

मुझे गंभीरता से लगता है कि GUIDs एक ओवरकिल है। कभी भी मेरी प्राथमिक कुंजी के रूप में GUIDs रखने की आवश्यकता नहीं थी।

— सिरिल गुप्ता

या, स्थान को बर्बाद करने और GUID के साथ टकराव को खत्म करने के बजाय, मूल प्राथमिक कुंजी और एक छोटी पहचानकर्ता की एक समग्र कुंजी बनाएं, जहां प्रत्येक सिंक स्रोत के लिए छोटा पहचानकर्ता अलग होता है।

— L --o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e

एक दुकान जो मैंने सभी लोगों के लिए इस्तेमाल की GUID के लिए काम किया, यहां तक ​​कि जब सार्वजनिक पहचानकर्ता उपलब्ध थे, जैसे कि आईएसओ देश या भाषा कोड। और तब भी जब एक बूलियन या CHAR(1)पर्याप्त होता, जैसे कि sex। कहने की जरूरत नहीं कि इसके साथ काम करना एक बुरा सपना था।

— लूमी

Answer 2

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

उदाहरण के लिए, (यूएस) राज्य के नामों और कोडों की एक तालिका में, या तो नाम या कोड प्राथमिक कुंजी हो सकता है - वे दो अलग-अलग उम्मीदवार कुंजी बनाते हैं, और उनमें से एक (सामान्य रूप से छोटा - कोड) को चुना जाता है प्राथमिक कुंजी। कार्यात्मक निर्भरता के सिद्धांत में (और निर्भरता में शामिल हों - 1NF 5NF के माध्यम से - यह उम्मीदवार कुंजी है जो प्राथमिक कुंजी के बजाय महत्वपूर्ण है।

एक काउंटर-उदाहरण के लिए, मानव नाम आमतौर पर प्राथमिक कुंजी के लिए एक बुरा विकल्प बनाते हैं। कई लोग हैं जो "जॉन स्मिथ" या कुछ अन्य समान नामों से जाते हैं; यहां तक ​​कि मध्य नामों को ध्यान में रखते हुए (याद रखें: हर किसी के पास एक नहीं है - उदाहरण के लिए, मैं नहीं), नकल के लिए बहुत गुंजाइश है। नतीजतन, लोग प्राथमिक कुंजी के रूप में नामों का उपयोग नहीं करते हैं। वे सामाजिक सुरक्षा संख्या (SSN) या कर्मचारी संख्या जैसी कृत्रिम कुंजी का आविष्कार करते हैं और व्यक्ति को नामित करने के लिए उनका उपयोग करते हैं।

एक आदर्श प्राथमिक कुंजी छोटी, अनोखी, यादगार और प्राकृतिक है। इन विशेषताओं में से विशिष्टता अनिवार्य है; बाकी को वास्तविक विश्व डेटा की बाधाओं को देखते हुए फ्लेक्स करना होगा।

जब किसी दी गई तालिका की प्राथमिक कुंजी निर्धारित करने की बात आती है, इसलिए, आपको यह देखना होगा कि वह तालिका क्या दर्शाती है। तालिका में स्तंभ मानों का क्या सेट या सेट विशिष्ट रूप से तालिका में प्रत्येक पंक्ति की पहचान करता है? वे उम्मीदवार कुंजी हैं। अब, यदि प्रत्येक उम्मीदवार की कुंजी में 4 या 5 कॉलम होते हैं, तो आप यह तय कर सकते हैं कि वे एक अच्छी प्राथमिक कुंजी (मुख्य रूप से लघुता के आधार पर) बनाने के लिए बहुत अनाड़ी हैं। उन परिस्थितियों में, आप एक सरोगेट कुंजी शुरू कर सकते हैं - एक कृत्रिम रूप से उत्पन्न संख्या। बहुत बार (लेकिन हमेशा नहीं) सरोगेट कुंजी के लिए एक साधारण 32-बिट पूर्णांक पर्याप्त है। आप तब इस सरोगेट कुंजी को प्राथमिक कुंजी के रूप में नामित करते हैं।

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

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

यह कुछ मामलों में एक बहुत ही कठिन दृश्य है।

मुझे GUID का उपयोग करने की कोई विशेष समस्या नहीं है जब उनकी आवश्यकता होती है, लेकिन वे बड़े होते हैं (16-64 बाइट्स में), और उनका उपयोग अक्सर किया जाता है। बहुत बार एक अच्छा 4-बाइट मान पर्याप्त होगा। GUID का उपयोग करना जहां एक 4-बाइट मान डिस्क स्थान को बर्बाद कर देगा, और डेटा तक अनुक्रमित पहुंच को धीमा कर देगा क्योंकि प्रति सूचकांक पृष्ठ पर कम मान हैं, इसलिए सूचकांक अधिक गहरा होगा और अधिक पृष्ठों को पढ़ने के लिए पढ़ना होगा जानकारी।

Comments

अमेरिकी राज्य के नाम के साथ अपने नमूने के बारे में, मैं एक अलग सरोगेट कुंजी पसंद करूंगा, क्योंकि कोड आपके नियंत्रण से परे कुछ हैं। यदि उन्हें किसी कारण से आपको समस्या के लिए बदलना चाहिए।

— डर्क वोल्मार

(जारी) उदाहरण के लिए, जर्मनी ने ४-अंकीय ज़िप कोड प्रणाली को ५-अंकीय प्रणाली के साथ १ ९९ ० में पुनः एकीकरण के बाद बदल दिया।

— डर्क वोल्मार

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

— एरिक

@Emtucifor: हाँ, हो सकता है कि ज़िप एक बहुत ही व्यावहारिक उदाहरण न हो, लेकिन मेरा कहना यह था कि यदि आपकी सरोगेट कुंजी का कुछ हिस्सा आपके नियंत्रण से बाहर है और जो भी कारण से आप परिवर्तन करते हैं, तो आप परेशानी में हैं। एक नई सामाजिक सुरक्षा नंबर योजना, एक नई ISSN योजना या - शायद अधिक यथार्थवादी बनाने वाली कंपनी के बारे में सोचें - एक कंपनी जो मर्ज होने के बाद एक नई उत्पाद आईडी प्रणाली बनाने का निर्णय लेती है, अपने विकास को समायोजित करने के लिए अपने कर्मचारियों को नए कर्मचारी नंबर आवंटित करती है आदि। सभी काल्पनिक उदाहरण, लेकिन, जिप शो के साथ मेरे पिछले उदाहरण के रूप में, कभी-कभी एक अच्छी तरह से स्थापित प्रणाली बदल सकती है।

— डिर्क वोल्मार

आपकी पहली बात सही है। इस अड़चन का एक नाम है। इसे "इकाई अखंडता" कहा जाता है। ईआई के लिए आवश्यक है कि प्रत्येक इकाई की एक विशिष्ट पहचान हो। प्राथमिक कुंजी अक्सर इस आवश्यकता को पूरा करती है, सिवाय इसके कि जब ऑटोनम्बर का उपयोग किया जाता है। ऑटोनम्बर के साथ, आप दो पंक्तियाँ प्राप्त कर सकते हैं जो समान हैं, सिवाय ऑटोनम्बर के। यह आमतौर पर इकाई अखंडता का उल्लंघन करता है।

— वाल्टर मिती

Answer 3

यह केवल एक धार्मिक मुद्दा है क्योंकि लोग एक सार्वभौमिक सही उत्तर चाहते हैं। तथ्य यह है कि आपकी टीम और यह SO थ्रेड दोनों ही इतनी असहमति दर्शाते हैं कि एक सुराग होना चाहिए कि आपके द्वारा वर्णित सभी समाधानों का उपयोग करने के लिए विभिन्न परिस्थितियों में अच्छे कारण हैं।

• सरोगेट कुंजी तब उपयोगी होती है जब तालिका में कोई अन्य विशेषता या विशेषताओं का सेट विशिष्ट रूप से पंक्तियों की पहचान करने के लिए उपयुक्त न हो।
• प्राकृतिक कुंजियों को प्राथमिकता दी जाती है, जब संभव हो, तालिका को अधिक मानव-पठनीय बनाने के लिए। प्राकृतिक कुंजियाँ भी एक आश्रित तालिका में विदेशी कुंजी को सरोगेट आईडी के बजाय वास्तविक मान रखने की अनुमति देती हैं। उदाहरण के लिए, जब आपको स्टोर करने की आवश्यकता होती है state(CA, TX, NY) तो आप char(2)इंट के बजाय प्राकृतिक कुंजी का उपयोग कर सकते हैं ।
• जहां उपयुक्त हो, वहां यौगिक प्राथमिक कुंजियों का उपयोग करें। एक " id" सरोगेट कुंजी को अनावश्यक रूप से न जोड़ें जब एक पूरी तरह से अच्छी यौगिक कुंजी मौजूद हो (यह विशेष रूप से कई-से-कई तालिकाओं में सच है)। प्रत्येक तालिका में तीन-स्तंभ कुंजी के लिए एक जनादेश निरर्थक है।
• GUID एक समाधान है जब आपको कई साइटों पर विशिष्टता को संरक्षित करने की आवश्यकता होती है। यदि आप अद्वितीय होने के लिए प्राथमिक कुंजी में मान की आवश्यकता है, तो वे भी उपयोगी हैं, लेकिन क्रम या लगातार नहीं।
• INT बनाम BIGINT: यह सामान्य नहीं है कि प्राथमिक कुंजियों के लिए किसी तालिका में 64-बिट श्रेणी की आवश्यकता होती है, लेकिन 64-बिट हार्डवेयर की बढ़ती उपलब्धता के साथ यह बोझ नहीं होना चाहिए, और अधिक आश्वासन देता है कि आप अतिप्रवाह नहीं करेंगे। INT बेशक छोटा है, इसलिए अगर स्पेस प्रीमियम पर है तो यह थोड़ा फायदा दे सकता है।

Comments

मैं उतना ही असहमत हूं जितना एक व्यक्ति संभवतः कर सकता है। प्राकृतिक कुंजी भयानक हैं। यदि कोई डेटा बदलना चाहता है तो क्या होगा? ओह, तुम नहीं कर सकते। समग्र प्राकृतिक कुंजियों पर जुड़ना एक दर्द है। उस संबंधित कुंजी को अपने सभी संबंधित तालिकाओं में ले जाना एक बेकार है।

— रॉबर्ट सी। बर्थ

@Robert: "ON UPDATE CASCADE" के बारे में पढ़ा। लेकिन मुझे वह मिलता है जो आप कह रहे हैं, और मैं सहमत हूं कि अधिकांश समय सरोगेट कुंजी का उपयोग करना सबसे अच्छा है, क्योंकि विशेषताओं को बदलने और गैर-अद्वितीय होने के अधीन हैं।

— बिल कार्विन

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

— FDCastel

@FD: मैं आपके असमान कथन से सहमत नहीं हूं, और मैं 1992 से SQL डेटाबेस के साथ विकास कर रहा हूं। लेकिन निश्चित रूप से यह सच है कि सरोगेट कीज अपरिवर्तनीय रहने में सक्षम हैं।

— बिल करविन

Answer 4

मुझे डेटाबेस प्रोग्रामर ब्लॉग पसंद है इस तरह की जानकारी के लिए एक स्रोत के रूप में ।

एक प्राथमिक कुंजी के लिए 3 कॉलम? मैं कहूंगा कि व्यापार नियमों की मांग के अनुसार कॉलम में अद्वितीय अवरोध होने चाहिए, लेकिन फिर भी मेरे पास एक अलग सरोगेट कुंजी होगी। यौगिक कुंजी का मतलब है कि व्यावसायिक तर्क कुंजी में प्रवेश करता है। यदि तर्क बदलता है, तो आपका पूरा स्कीमा खराब हो जाता है।

Comments

: वे अपने लिंक बदल गया है, यहाँ अद्यतन बुकमार्क है database-programmer.blogspot.com/2008/09/...

— ब्रायन Rehbein

बस इस तरह एक परियोजना विरासत में मिली। और बहुत पहले वे स्कीमा को उड़ा देना चाहते थे। सरोगेट कीज़ FTW। आपके DB FTL में बिजनेस लॉजिक।

— जेसन

Answer 5

मुझे मेरा अद्वितीय पसंद है।

Answer 6

थोड़ा बंद विषय, लेकिन मैं में झंकार के लिए मजबूर महसूस कर रहा हूँ ...

यदि आपकी प्राथमिक कुंजी एक GUID है, तो इसे एक क्लस्टर इंडेक्स न बनाएं । चूंकि GUIDs गैर-अनुक्रमिक होते हैं, डेटा लगभग हर डालने के दौरान डिस्क पर फिर से व्यवस्थित किया जाएगा। (Yuck।) यदि GUID का उपयोग प्राथमिक कुंजी के रूप में किया जाता है, तो उन्हें गैर-अनुक्रमित अनुक्रमित होना चाहिए।

Comments

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

— marc_s

यह वास्तव में सटीक नहीं है। डेटा क्रम में डाला जाएगा, जो कि GUID की यादृच्छिक प्रकृति को देखते हुए अंत में पूरे टेबल पर कहीं भी हो सकता है। बंद मौके पर कि कमरा नहीं है, एक पेज स्प्लिट होगा, लेकिन निश्चित रूप से "हर डालने के दौरान डिस्क पर फिर से व्यवस्थित नहीं" भी नहीं।

— राल्फ शिलिंग्टन

@ राल्फ, आप सही कह रहे हैं, हर कोई सम्मिलित नहीं है, लेकिन एक 20x प्रदर्शन हिट के लिए पर्याप्त है। sql-server-performance.com/articles/per/…

— पोर्टमैन

SQL सर्वर फंक्शन newfterentialid () GUIDs के साथ सूचकांक विखंडन की समस्या को हल करता है (हालाँकि 24 बाइट्स अभी भी एक अत्यधिक है अगर आपको वैश्विक विशिष्टता की आवश्यकता नहीं है)। Msdn.microsoft.com/en-us/library/ms189786.aspx देखें।

— एरिक

Answer 7

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

अब, सरोगेट कुंजी के चयन के लिए, मैं पहचान कॉलम के साथ छड़ी करता हूं (मैं ज्यादातर एमएस SQL ​​सर्वर में काम करता हूं)। GUID बहुत बड़े हैं और Microsoft उन्हें PK के रूप में उपयोग करने के खिलाफ अनुशंसा करता है। यदि आपके पास एक से अधिक सर्वर हैं, तो आपको केवल 10 या 20 या जो भी आपको लगता है कि सर्वर की अधिकतम संख्या को आपके द्वारा सिंक करने / विस्तारित करने की आवश्यकता है, और प्रत्येक तालिका के लिए प्रत्येक तालिका के लिए बीज को बढ़ाना है। , और आपके पास डेटा टकराव कभी नहीं होगा।

बेशक, वेतन वृद्धि के कारण, मैं पहचान कॉलम को एक बिगआईंट (अन्यथा एक लंबे [64 बिट्स] के रूप में जाना जाता है) बनाता हूं।

थोड़ा गणित करें, भले ही आप वेतन वृद्धि 100 करें, फिर भी आप अपनी तालिका में 92,233,720,368,547,758 (> 92 क्वाड्रिलियन) पंक्तियाँ रख सकते हैं।

Answer 8

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

सबसे पहले, परिभाषा का उपयोग करें कि "कुंजी" एक विशेषता या विशेषताओं का सेट है जो तालिका के भीतर अद्वितीय होना चाहिए,

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

1. चाइल्ड टेबल में एक या कई रिकॉर्ड के लिए शर्तों के रूप में उपयोग करने के लिए जो इस मूल तालिका से संबंध रखते हैं। (स्पष्ट रूप से या स्पष्ट रूप से उन बच्चों की तालिकाओं में एक विदेशी कुंजी को परिभाषित करना)
2. (संबंधित) यह सुनिश्चित करना कि बच्चे का रिकॉर्ड पैरेंट टैब में माता-पिता का रिकॉर्ड होना चाहिए;

3. तालिका में एक विशिष्ट रिकॉर्ड / पंक्ति को तेजी से खोजने की आवश्यकता वाले प्रश्नों की गति को बढ़ाने के लिए।

4. तालिका में सम्मिलित होने से समान तार्किक इकाई का प्रतिनिधित्व करने वाली डुप्लिकेट पंक्तियों को रोककर डेटा स्थिरता सुनिश्चित करने के लिए। (इसे अक्सर "प्राकृतिक" कुंजी कहा जाता है, और इसमें तालिका (इकाई) विशेषताएँ शामिल होनी चाहिए जो अपेक्षाकृत अपरिवर्तनीय होती हैं।)

स्पष्ट रूप से, कोई भी गैर-अर्थपूर्ण, गैर-प्राकृतिक कुंजी (जैसे एक GUID या एक ऑटो-जनरेट किया गया पूर्णांक # 4 को संतुष्ट करने में पूरी तरह असमर्थ है।

लेकिन अक्सर, कई (सबसे) तालिकाओं के साथ, एक पूरी तरह से प्राकृतिक कुंजी जो # 4 प्रदान कर सकती है, अक्सर कई विशेषताओं से युक्त होगी और अत्यधिक विस्तृत होगी, या इतनी व्यापक होगी कि इसका उपयोग # 1, # 2, या # 3 के लिए अस्वीकार्य होगा। प्रदर्शन के परिणाम।

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

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

Comments

SQL सर्वर फ़ंक्शन newfterentialid () GUIDs की अनुक्रमणिका विखंडन समस्या को हल करता है (हालाँकि 24 बाइट्स अभी भी एक अत्यधिक है अगर आपको वैश्विक विशिष्टता की आवश्यकता नहीं है)। Msdn.microsoft.com/en-us/library/ms189786.aspx देखें।

— 17

उफ़, मेरा मतलब था 16 बाइट्स।

— एरिक

Answer 9

एक चीज जो आपको कभी नहीं करनी चाहिए वह है स्मार्ट कुंजी का उपयोग। यह एक कुंजी है जहां रिकॉर्ड के बारे में जानकारी कुंजी में ही कोडित होती है, और यह अंततः आपको काट लेगी।

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

एक अन्य जगह, रिकॉर्ड के लिए प्राथमिक कुंजी के रूप में पेड़ में स्थान का इस्तेमाल किया। तो निम्नलिखित की तरह रिकॉर्ड होगा।

Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

बेशक, पहली चीज जो ग्राहक चाहते थे, वह चारों ओर के पेड़ में वस्तुओं को स्थानांतरित करने का एक तरीका था। सॉफ्टवेयर का पूरा सेट होने से पहले ही मर गया।

कृपया, कृपया, कृपया, यदि आप ऐसा कोड लिख रहे हैं जिसे मुझे कभी बनाए रखना है, तो कृपया एक स्मार्ट कुंजी का उपयोग न करें!

Comments

मैं तहे दिल से सहमत हूं। स्मार्टकी = गूंगा।

— रॉबर्ट सी। बर्थ

इसका मतलब यह नहीं है कि प्राकृतिक कुंजियाँ गूंगी हैं। लेकिन अच्छी बात है।

Answer 10

मैं प्राथमिक कुंजी के रूप में ऑटो-इंक्रीमेंट का प्रशंसक हूं। मैं अपने दिल में गहराई से जानता हूं कि यह एक पुलिस-आउट है, लेकिन जब इसे जोड़ा गया था तो डेटा को सॉर्ट करना इतना आसान हो गया (ORDER BY ID DESC, f'r उदाहरण)।

3 कॉलम लगता है कि मानवीय रूप से तोते के लिए कठोर है।

और यह व्यापार-बंद है - आपको कितने रिलेशनल क्षमता की आवश्यकता है, बनाम यह एक मानव पूछताछ करने के लिए समझ में आता है (बनाम संग्रहीत-प्रक्रिया या प्रोग्रामेटिक इंटरफ़ेस)।

ऑटो-इन्क्रीमेंट हम इंसानों के लिए है। :-(

Answer 11

आम तौर पर, यह निर्भर करता है।

व्यक्तिगत रूप से, मुझे ऑटोइंटरमेंट इनट्स पसंद हैं।

लेकिन, एक बात जो मैं आपको बता सकता हूं वह यह है कि अन्य स्रोतों के डेटा को कभी भी अपनी कुंजी के रूप में भरोसा न करें। मैं कसम खाता हूँ, हर बार जब मैंने किया है कि यह मुझे काटने के लिए वापस आता है। खैर, फिर कभी!

Answer 12

कम से कम 3 कॉलम होने चाहिए जो प्राथमिक कुंजी बनाते हैं।

मुझे यह समझ में नहीं आता है।

क्या आप "प्राकृतिक कुंजी" के बारे में बात कर रहे हैं, उदाहरण के लिए "नाम और जन्म तिथि"? यदि यह मौजूद है, तो एक प्राकृतिक कुंजी आदर्श हो सकती है, लेकिन एक प्राकृतिक कुंजी के लिए अधिकांश उम्मीदवार या तो अद्वितीय नहीं होते हैं (एक ही नाम वाले कई लोग) या निरंतर नहीं (कोई अपना नाम बदल सकता है)।

इंट / बिगआईंट जो कि ऑटोइंक्रिमेंट पर्याप्त प्राथमिक कुंजी हैं।

मुझे गाइड पसंद है। ऑटोइन्क्रिमेंट के साथ एक संभावित समस्या यह है कि मूल्य (उदाहरण के लिए "ऑर्डर आईडी") डेटाबेस उदाहरण (उदाहरण के लिए "बिक्री डेटाबेस") द्वारा सौंपा गया है ... जो पूरी तरह से काम नहीं करेगा (इसके बजाय आपको यौगिक कुंजियों की आवश्यकता है) आपको कभी भी एक से अधिक डेटाबेस इंस्टेंस द्वारा बनाए गए डेटा को मर्ज करने की आवश्यकता होती है (उदाहरण के लिए अपने स्वयं के डेटाबेस के साथ कई बिक्री कार्यालयों से)।

Comments

प्राथमिक कुंजी अद्वितीय होने के लिए आवश्यक हैं, लेकिन स्थिर होने के लिए आवश्यक नहीं हैं। इसलिए "ON UPDATE CASCADE" के साथ घोषित विदेशी कुंजी। लेकिन यह धारणा बनाते हुए कि प्राथमिक कुंजी स्थिर है कई अनुप्रयोगों को सरल बनाने में मदद करता है। यह सरोगेट कुंजी का एक लाभ है।

— बिल करविन

Answer 13

आरई गाइड

देखें कि क्या यह वास्तव में वास्तव में वास्तव में बड़ा डेटाबेस, बहुत सारे लोड और तेजी से पहुंच वाला है।

मेरी पिछली नौकरी में, जहां हमारे पास 100 से 500 मिलियन रिकॉर्ड्स के डेटाबेस थे, हमारे डेटाबेस के लोगों ने GUID के खिलाफ दृढ़ता से तर्क दिया, और उचित रूप से दशमलव संख्या के लिए। उन्होंने महसूस किया कि (Oracle के तहत) एक स्ट्रिंग गाइड के लिए आंतरिक भंडारण में आकार अंतर - बनाम- एक दशमलव मान लुकअप में बहुत ध्यान देने योग्य अंतर होगा। (बड़ी कुंजियाँ = गहरे पेड़ों को उखाड़ने के लिए)

GUID की यादृच्छिक प्रकृति भी अनुक्रमणिका पृष्ठों के लिए भरण-कारक को काफी कम कर देती है - यह नाटकीय रूप से फाड़ और डिस्क I / O को बढ़ाता है।

Comments

"फिल-फैक्टर को कम करता है"? निश्चित नहीं है कि इसका क्या मतलब हो सकता है कि फिल-फैक्टर एक शॉट डील है, जो इंडेक्स के निर्माण के समय इंडेक्स के लीफ-लेवल पर निशुल्क स्थान के प्रतिशत के रूप में परिभाषित किया गया है। GUID मूल्यों को उस फ्री-स्पेस में लीफ-लेवल की चौड़ाई पर उनके यादृच्छिक प्रकृति वितरण द्वारा प्रदान करता है जो कि फिल-फैक्टर प्रदान करता है।

— राल्फ शिलिंग्टन

कब से एक गाइड एक स्ट्रिंग है? GUID को किसी भी सम्मानित DBMS द्वारा आंतरिक रूप से 16 बाइट्स के रूप में संग्रहीत किया जाना चाहिए। हेक्स प्रतिनिधित्व में 32 बाइट्स के रूप में संग्रहीत करना अचेतन होगा! (या डैश के साथ 36, या घुंघराले ब्रेसिज़ के साथ 38)

— एरिक

Answer 14

ऑटो वेतन वृद्धि कॉलम। मैं SQL सर्वर या Oracle के साथ मूल रूप से अपना कोड कार्य करने में सक्षम हूं, एक पहचान का उपयोग करके दूसरे को अपने DAL के माध्यम से अनुक्रमों का उपयोग करके, और मैं अधिक खुश नहीं हो सकता। मैं मानता हूँ, GUID कभी-कभी आवश्यक होते हैं यदि आप प्रतिकृति बनाने या डेटा भेजने के लिए इसे बाद में Afer प्रसंस्करण पर प्राप्त करते हैं।

Answer 15

मैंने हमेशा एक सरोगेट कुंजी का उपयोग किया है - एक used आईडी ’नामक एक ऑटोइन्क्रिमेंटिंग पूर्णांक। मैं ऐसा करने के लिए बहुत सारे कारण देख सकता हूँ तब भी जब दूसरा विकल्प स्पष्ट हो:

• संगति
• डेटा स्वतंत्र (विशिष्ट, प्रारूप में परिवर्तन द्वारा नष्ट नहीं किया गया)
• मानव पठनीय

... और नहीं समझदार कारण:

• जुड़ने में अस्पष्टता? - अलियासिंग टेबल एक बेहतर अभ्यास है, आईएमएचओ
• इष्टतम तालिकाओं? - प्रति प्रविष्टि एक बाइट निकालना समय से पहले अनुकूलन, IMHO है
• प्रति-तालिका निर्णय - अब लगातार नहीं
• स्केलिंग की समस्या? - एह? क्यों?
• पदानुक्रमित डेटा संरचना? - जो कि धर्म का एक अन्य विषय है। यह कहने के लिए पर्याप्त है कि मैं सिद्धांत में कुछ परिस्थितियों में एक प्रशंसक हूं, लेकिन व्यवहार में कभी नहीं :)

समझदार कारणों के बारे में जो मैंने अभी तक नहीं सोचा है या अभी तक नहीं आया है, हमेशा स्वागत किया जाता है ...

Answer 16

यह एक क्लासिक "यह निर्भर करता है" है। हर प्रोजेक्ट के लिए कोई एक सही जवाब नहीं है। मुझे अलग-अलग स्थितियों के लिए अलग-अलग चीजें पसंद हैं। यह इस बात पर निर्भर करता है कि मैं एक ORM का उपयोग कर रहा हूं या क्या यह समर्थन करता है। यह समग्र वास्तुकला (वितरित या नहीं, आदि) पर निर्भर करता है। बस एक उठाएं जो आपको लगता है कि काम करेगा और टैब और रिक्त स्थान पर बहस करने के लिए आगे बढ़ेगा।

Comments

वह अभी भी जानना चाहता है कि यह कैसे निर्भर करता है; केवल इन के बारे में जागरूकता के साथ किसी को चुनने के लिए खुद पर भरोसा करने के लिए आ सकता है ...

— निकोलस लियोनार्ड

Answer 17

मैं आकार के आधार पर विकल्प # 1 या # 3 का उपयोग करता हूं, कनेक्ट करने वाले लोगों की संख्या, और यह एक एकाधिक डेटाबेस सर्वर की स्थिति है या नहीं।

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

Answer 18

मैंने केवल एक ऑटो-इंक्रीमेंट इंट या GUID का उपयोग किया है। 99% समय मैंने ऑटो-इंक्रीमेंट इंट का उपयोग किया है। जब मैंने पहली बार डेटाबेस के बारे में सीखा और इसका उपयोग न करने के कारण कभी नहीं चला, तो यह सिर्फ वही है जो मुझे इस्तेमाल करने के लिए सिखाया गया था (हालाँकि मुझे कारणों के बारे में पता है कि एक GUID बेहतर क्यों होगा)।

मुझे ऑटो इंक्रीमेंट इनट्स पसंद है क्योंकि यह पठनीयता के साथ मदद करता है। उदाहरण के लिए मैं कह सकता हूं "रिकॉर्ड 129383 पर एक नज़र डालें" और किसी के लिए इसमें जाना और उसे ढूंढना बहुत आसान है। एक GUID के साथ ऐसा करना लगभग असंभव है।

Comments

तुमने ऐसा क्यों कहा? ऐसा लगता है कि कई लोग ऑटो-इंक्रीमेंट पूर्णांक का उपयोग करते हैं। यह बुरा नहीं हो सकता है अगर यह काम करता है और आपकी आवश्यकता के लिए अच्छी तरह से काम करता है।

— dtc

Answer 19

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

• क्या प्राथमिक कुंजी की परिभाषा अत्यधिक जटिल नहीं है? क्या यह "सर्वोत्तम-अभ्यास" का पालन करने के लिए अनावश्यक जटिलता को पेश करने से बचता है?
• क्या एक बेहतर संभव प्राथमिक कुंजी है जिसे संभालने के लिए डेटाबेस के लिए कम ओवरहेड की आवश्यकता होगी (यानी INTEGER बनाम VARCHAR, आदि)?
• क्या मैं निश्चित रूप से निश्चित हूं कि मेरी प्राथमिक कुंजी की विशिष्टता और परिभाषित-नेस अपरिवर्तनीय परिवर्तन नहीं होगा?

यह अंतिम संभावना है कि अधिकांश लोग GUID या स्व-संवर्धित पूर्णांक कॉलम जैसी चीजों का उपयोग करने के लिए क्या कहते हैं, क्योंकि पते, फोन नंबर, पहले / अंतिम नाम, आदि जैसी चीजों पर भरोसा करते हैं, बस इसे काटें नहीं। जिन लोगों के बारे में मैं सोच सकता हूं, वे केवल SSNs हैं, लेकिन तब मैं उन 100% के बारे में निश्चित नहीं हूं जो हमेशा के लिए अद्वितीय हैं।

उम्मीद है कि यह कुछ स्पष्टता को जोड़ने में मदद करता है ...

Comments

कुछ ऐतिहासिक मामले हैं जहां एसएसएन अद्वितीय नहीं हैं।

— बिल करविन 21

Answer 20

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

Comments

क्या इसका मतलब यह है कि जब भी आप कर सकते हैं 'ऑटो-इंक्रीमेंटिंग पूर्णांक से बचें' मेरी समझ यह थी कि उद्योग के विशेषज्ञों ने सोचा था कि बड़े पैमाने पर डेटाबेस में सबसे अच्छा प्रदर्शन न्यूनतम-हस्ताक्षर, अनुक्रमित, वृद्धिशील एकल-स्तंभ पीके से आता है।

— हरदौरी

मैंने हमेशा सोचा था कि विशेषज्ञों ने नौकरी के लिए सबसे अच्छा उपकरण का इस्तेमाल किया

— एंड्रयू जी। जॉनसन

Answer 21

लगभग हमेशा पूर्णांक।

उनके पास प्रक्रिया के छोटे / तेज़ होने के अलावा अन्य अच्छे कारण हैं। जो आप बल्कि "404040" या "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c" लिखेंगे?

Comments

उत्तरार्द्ध एक पूर्णांक हो सकता है, डैश के साथ और आधार 16 में जोड़ा जा सकता है। लेकिन हां, 404040 लंबे GUID की तुलना में प्रक्रिया करने के लिए तेज़ है। फिर से, 0 प्रोसेस करने के लिए और भी तेज़ है क्योंकि इसके लिए एक बिट डेटा की आवश्यकता नहीं है!

— स्ट्रैजर

Answer 22

केवल थोड़ा प्रासंगिक है, लेकिन एक चीज जो मैंने हाल ही में शुरू की है जब मेरे पास छोटे वर्गीकरण टेबल हैं (अनिवार्य रूप से जो कोड में ENUM का प्रतिनिधित्व करेंगे) यह है कि मैं प्राथमिक कुंजी को एक चार (3) या चार (4) बनाऊंगा। फिर मैं उन प्राथमिक कुंजियों को लुकअप वैल्यू का प्रतिनिधि बनाता हूं।

उदाहरण के लिए, हमारे पास हमारे आंतरिक बिक्री एजेंटों के लिए एक उद्धरण प्रणाली है। हमारे पास "मूल्य श्रेणियां" हैं जो प्रत्येक बोली लाइन आइटम को असाइन किया गया है ... इसलिए मेरे पास 'tCostCategories' नामक एक प्रकार की लुकअप तालिका है, जहां प्राथमिक कुंजी 'MTL', 'SVC', 'TRV', 'TAX' है। 'ओडीसी'। लुकअप टेबल के अन्य कॉलम अधिक विवरण संग्रहीत करते हैं, जैसे कि कोड के सामान्य अंग्रेजी अर्थ, "सामग्री", "सेवा", "यात्रा", "कर", "अन्य प्रत्यक्ष लागत", और इसके आगे।

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

1 पार्टनंबर $ 40 एमटीएल
2 अन्यपार्टनंबर $ 29.99 एसवीसी
3 पार्टनंबर 2 $ 150 टीआरवी

यह बहुत आसान है कि श्रेणियों का प्रतिनिधित्व करने के लिए एक इंट का उपयोग करना और फिर सभी लाइनों पर 1, 2, 3 को जोड़ना - आपके पास डेटा ठीक आपके सामने है, और प्रदर्शन बिल्कुल प्रभावित नहीं होता है (ऐसा नहीं है कि मैं ' वास्तव में परीक्षण किया गया है।)

जहाँ तक असली सवाल है ... मुझे रोवुइद यूनीकॉलीफायर्स पसंद है। मैं इस पर 100% नहीं हूँ, लेकिन सभी पंक्तियों में आंतरिक RowGuid के वैसे भी नहीं है ?? यदि ऐसा है, तो राउजीड का उपयोग वास्तव में ints (या इस मामले के लिए कुछ और) की तुलना में कम जगह लेगा। मुझे पता है कि अगर यह एम $ के लिए ग्रेटप्लेंस में उपयोग करने के लिए पर्याप्त है तो यह मेरे लिए काफी अच्छा है। (क्या मुझे डकार लेना चाहिए ??)

Answer 23

ओह, एक और कारण मैं GUID का उपयोग करता हूं - मैं एक पदानुक्रमित डेटा संरचना का उपयोग करता हूं। अर्थात्, मेरे पास एक तालिका 'कंपनी' और एक तालिका 'विक्रेता' है, जिसके लिए प्राथमिक कुंजी मेल खाती है। लेकिन मेरे पास एक टेबल 'निर्माता' भी है जो कंपनी से 'विरासत में' भी है। वे फ़ील्ड जो निर्माता और निर्माता के लिए सामान्य हैं, वे उन तालिकाओं में प्रकट नहीं होते - वे कंपनी में दिखाई देते हैं। इस सेटअप में, Guids की तुलना में int का उपयोग अधिक दर्दनाक है। बहुत कम में, आप पहचान प्राथमिक कुंजी का उपयोग नहीं कर सकते।

Comments

हां, आप कर सकते हैं, आप केवल उप-तालिका नहीं बनाते हैं पहचान की संपत्ति है, इसके बजाय उन्हें सुपरटेप तालिका मूल्य के स्पष्ट आवेषण मिलते हैं। कृपया stackoverflow.com/questions/2112882/…

— एरिक

Answer 24

मुझे प्राकृतिक कुंजी पसंद है, जब भी मैं उन पर भरोसा कर सकता हूं। मैं उन छोटे-छोटे प्रदर्शन मूल्य का भुगतान करने के लिए तैयार हूं, जो विषय वस्तु विशेषज्ञों के लिए समझ बनाने वाली चाबियों का उपयोग करने के लिए हैं।

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

रिश्तों का वर्णन करने वाली तालिकाओं के लिए, मैं एक यौगिक कुंजी का उपयोग करता हूं, जहां प्रत्येक घटक एक इकाई का संदर्भ देता है जो रिश्ते में भाग लेता है, और इसलिए एक इकाई तालिका में एक पंक्ति। फिर, एक यौगिक कुंजी का उपयोग करने के लिए प्रदर्शन हिट आमतौर पर न्यूनतम है।

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

Comments

कृपया कुछ नमूना भरोसेमंद प्राकृतिक कुंजियों का वर्णन करें?

— एरिक

"भरोसेमंद" अपने आप में एक कुंजी की संपत्ति नहीं है। बल्कि, यह डेटा की आपूर्ति करने वाले लोगों के संदर्भ में कुंजी के साथ करना है। यदि आप किसी ऐसे व्यक्ति को बेचा जाने वाला ऐप लिख रहे हैं जो वास्तव में डेटा का प्रबंधन करेगा, तो आपको यह अनुमान लगाना होगा कि कौन सी कुंजी ग्राहक के लिए भरोसेमंद होगी या नहीं। ग्राहकों की विविधता को देखते हुए, आप लगभग निश्चित रूप से अपने ग्राहक के कुछ अंश के लिए गलत अनुमान लगाने जा रहे हैं।

— वाल्टर मिती

ऊपर कहा गया है, यहाँ एक कुंजी का एक उदाहरण है कि हम जिस तरह से जब वापस भरोसा किया। हमारे पास पाठ्यक्रमों के बारे में एक डेटाबेस था। इसमें पाठ्यक्रम के बारे में पाठ्यपुस्तक और अन्य पाठ्यक्रम सामग्री, अनुसूचित पाठ्यक्रम प्रसाद, प्रशिक्षक शामिल थे जो पाठ्यक्रम, पाठ्यक्रम पूर्वापेक्षा, ट्यूशन और इतने पर पढ़ाने के लिए योग्य थे। जब पाठ्यक्रम के विकास ने एक नया पाठ्यक्रम बनाया, तो पहली चीज़ जो उन्होंने की, वह थी एक कोर्स कोड असाइन करना। वे यह सुनिश्चित करने के लिए ज़िम्मेदार थे कि पाठ्यक्रम कोड अद्वितीय थे, और उन पाठ्यक्रमों ने अपना कोड कभी नहीं बदला, एक बार सौंपा। यह डेटा का हिस्सा था जैसा हमें दिया गया था।

— वाल्टर मिती

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

— वाल्टर मिती

Answer 25

Guids.period।

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

---

मेरे कथन को स्पष्ट करने के लिए अद्यतन।

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

GUID का उपयोग करते समय आप कहीं भी आईडी जनरेट कर सकते हैं। यह एक दूरस्थ सर्वर, आपके वेब ऐप, डेटाबेस के भीतर या मल्टीमास्टर स्थिति में भी कई डेटाबेस के भीतर उत्पन्न हो सकता है।

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

निश्चित रूप से, GUIDs के उपयोग का अर्थ है कि आपके पास रात्रिकालीन रींडेक्सिंग प्रक्रियाएँ होनी चाहिए। हालाँकि, अगर आप किसी ऑटो इंप्रूव्ड INT के अलावा कुछ भी इस्तेमाल कर रहे हैं तो आपको ऐसा करना चाहिए। बिल्ली, यहां तक ​​कि एक INT के साथ प्राथमिक के रूप में यह संभावना है कि आपके पास अन्य सूचकांक हैं जिन्हें विखंडन से निपटने के लिए पुनर्जीवित करने की आवश्यकता है। इसलिए, GUID का उपयोग करने से वास्तव में एक और समस्या नहीं जुड़ती है क्योंकि उन कार्यों को बिना प्रदर्शन किए किए जाने की आवश्यकता होती है।

यदि आप वहाँ के बड़े ऐप पर नज़र डालते हैं तो आपको कुछ महत्वपूर्ण सूचनाएँ मिलेंगी: वे सभी कुंजियों के रूप में बेस 64 एनकोडेड GUID का उपयोग करते हैं। इस का कारण यह आसान है, GUIDs के उपयोग आप पैमाने पर करने के लिए सक्षम बनाता है बाहर आसानी से जबकि वहाँ जब INTs बाहर पैमाने पर करने का प्रयास कर के माध्यम से कूदने के लिए हुप्स का एक बहुत हो सकता है।

हमारा नवीनतम ऐप भारी आवेषण की अवधि से गुजरता है जो लगभग एक महीने तक रहता है। उसके बाद 90 +% प्रश्न सभी रिपोर्टिंग के लिए चुने गए हैं। क्षमता बढ़ाने के लिए मैं इस बड़ी प्रविष्टि अवधि के दौरान अतिरिक्त DB सर्वर ला सकता हूं; और बाद में रिपोर्टिंग के लिए आसानी से उन लोगों को एक ही डीबी में मिला देते हैं। इंट्स के साथ ऐसा करने का प्रयास एक पूर्ण दुःस्वप्न होगा।

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

Comments

आपने कभी अपने अनुक्रमित के भरण कारक की जांच की? GUID की यादृच्छिक प्रकृति का 'उन्हें स्वेस पनीर - नाटकीय रूप से उनकी प्रभावशीलता को कम करता है।

— Stephbu

"Guids.period": यह इतना गलत है। जहां उचित हो वहां GUID का उपयोग किया जाना चाहिए। जैसा कि अन्य टिप्पणीकार ने बताया, यह प्रोग्रामर के रूप में जीवन को आसान बना सकता है, लेकिन डीबी के समग्र आकार और प्रदर्शन को प्रभावित करता है।

— मिच गेहूं

दिन के अंत में, मैं बिना किसी समस्या के कई डेटाबेस सर्वर पर अपने ऐप्स को स्केल कर सकता हूं। लेकिन मुझे लगता है कि आप लोग छोटी साइटों पर काम करते हैं।

— 18

तार्किक प्राथमिक कुंजी के लिए GUID ठीक हो सकता है, लेकिन कभी भी अपनी CLUSTERING कुंजी के रूप में एक GUID कॉलम का उपयोग न करें - आप सूचकांक प्रदर्शन में अग्रणी होकर डूबेंगे .....

— marc_s

मैं निश्चित रूप से "Guids.period" की घोषणा नहीं करूंगा। इस विषय पर - वास्तव में यहां तक ​​कि एक उद्योग में तो 'सर्वोत्तम प्रथाओं' से भरा हुआ है कि इस तरह का बयान आपको डिफ़ॉल्ट रूप से (विशेष रूप से उस बयान के साथ) अस्थिर जमीन पर रखता है। GUID के रूप में निपटने के लिए जितना भी दर्दनाक हो, कुछ कठिन औचित्य की आवश्यकता होती है और जैसा कि जेएल कहते हैं, मुझे लगता है कि हम में से अधिकांश इसे एक अंतिम उपाय मानेंगे। यह ऐसा है मानो आपने शेष सूत्र को पढ़े बिना पोस्ट किया हो।

— हरदौरी

Answer 26

यह एक जटिल विषय है कि आपने इसे महसूस किया है या नहीं। इस StackOverflow FAQ पर अनुभाग के अंतर्गत आते हैं।

मुझे यहां किस तरह के सवाल नहीं पूछने चाहिए?

ऐसे प्रश्न पूछने से बचें, जो व्यक्तिपरक, तर्कपूर्ण हों, या विस्तारित चर्चा की आवश्यकता हो। यह सवालों के लिए एक जगह है जिसका जवाब दिया जा सकता है!

इस पर वर्षों से बहस चल रही है और वर्षों तक इस पर बहस जारी रहेगी। मेरे द्वारा देखे जाने वाले सर्वसम्मति के संकेत केवल यह हैं कि यदि आप एक OO पुरुष (GUIDs जाने का एकमात्र तरीका हैं!) पूछ रहे हैं, तो इसके आधार पर उत्तर कुछ हद तक अनुमानित हैं! एक डेटा मॉडलर (प्राकृतिक कुंजी केवल जाने का एकमात्र तरीका है!)। या एक प्रदर्शन उन्मुख DBA (INTs जाने का एकमात्र तरीका है!)।

Comments

मैं चर्चा को लंबा नहीं होने दूंगा। मैं आम सहमति को देखने के लिए उत्सुक था।

— Perpetualcoder

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

— निकोलस लियोनार्ड