मेरे पास चार स्तंभों वाली एक तालिका है जो सभी गैर-अशक्त हैं, और डेटा ऐसा है कि सभी चार को एक अद्वितीय रिकॉर्ड को भेद करने की आवश्यकता है। इसका मतलब यह है कि अगर मैं एक प्राथमिक कुंजी बनाने के लिए था, तो इसमें सभी कॉलम शामिल करने की आवश्यकता होगी। तालिका के खिलाफ क्वेरी लगभग हमेशा एक रिकॉर्ड को वापस खींचने के लिए होगी, अर्थात सभी कॉलम क्वेरी में फ़िल्टर किए जाएंगे।
चूँकि हर स्तंभ को खोजा जाना आवश्यक है, क्या मुझे प्राथमिक रूप से कोई लाभ होता है (अभिलेखों की विशिष्टता को लागू करने के अलावा)?
जवाबों:
आपके मामले में ये क्षेत्र प्राकृतिक कुंजी हैं।
सरोगेट कुंजी:
सरोगेट कीज़ एक ऐसी कुंजी है जिसका कोई "व्यावसायिक" अर्थ नहीं है और पूरी तरह से तालिका में रिकॉर्ड की पहचान करने के लिए उपयोग किया जाता है। ऐसी कुंजियाँ या तो डेटाबेस जेनरेट की जाती हैं (उदाहरण: SQL सर्वर में पहचान, Oracle में अनुक्रम, DB2 UDB आदि में अनुक्रम / पहचान) या सिस्टम जनरेटेड मान (जैसे स्कीमा में तालिका के माध्यम से उत्पन्न)।
प्राकृतिक कुंजी:
कुंजी स्वाभाविक हैं यदि इसका प्रतिनिधित्व करने वाला गुण डेटाबेस स्कीमा के स्वतंत्र रूप से पहचान के लिए उपयोग किया जाता है। मूल रूप से इसका मतलब यह है कि अगर लोग उनका उपयोग करते हैं तो चाबियाँ स्वाभाविक हैं: चालान-संख्या, टैक्स-आईडीएस, एसएसएन आदि।
प्राथमिक कुंजी के लिए प्राकृतिक कुंजी बनाम सरोगेट कुंजी
मैं अलग-अलग व्यवसाय और डेटाबेस मॉडल प्रबंधन के लिए सरोगेट कुंजी जोड़ना पसंद करता हूं। अन्य प्रश्न प्राथमिक कुंजी पर संकुल और गैर-अनुक्रमित सूचकांक का उपयोग कर रहा है .. यदि आप तालिका में परिवर्तन करते हैं (गैर स्थैतिक तालिका, इसमें उच्च गहन आवेषण या अपडेट है), तो आपको गैर-मोनोटोनिक कुंजी पर क्लस्टर सूचकांक का उपयोग करने के मामले में प्रदर्शन के साथ समस्या होगी।
यह आमतौर पर सिफारिश की जाती है कि आपके पास ऐसी स्थितियों में एक सरोगेट कुंजी है, इसलिए अन्य तालिकाओं में विदेशी कुंजी (और कोई भी रिकॉर्ड संदर्भ जो बाहरी रूप से संग्रहीत किया जा सकता है, जैसे कि उन्हें क्वेरी स्ट्रिंग्स पर ले जाया जाता है जहां एक http (s) अनुरोध एक को संदर्भित करता है रेकॉर्ड्स) को संदर्भित करने के लिए कुछ है अगर पंक्ति में डेटा बदलता है तो नहीं बदलेगा। यदि आप ऐसा करते हैं तो वह आपकी प्राथमिक कुंजी होगी।
यदि आप इस तरह की सरोगेट कुंजी नहीं जोड़ते हैं, तो यह देखते हुए कि आप सभी चार स्तंभों तक पहुंचने वाले डेटा का वर्णन करते हैं क्योंकि प्राथमिक कुंजी एक नुकसान नहीं होगी। यदि आप कुंजी को टेबल के लिए क्लस्टर किए गए इंडेक्स बनाते हैं तो यह ऐसे अनुरोधों में मदद करेगा क्योंकि किसी दिए गए पंक्ति के डेटा को खोजने के लिए डिस्क पर बी-ट्री में एक स्तर होगा।
प्राथमिक कुंजी के रूप में समग्र कुंजी भी इंडेक्स आकार के मुद्दों में चलती है जो डिस्क उपयोग, io गति और बैकअप को प्रभावित कर सकती है। आप प्राथमिक कुंजियों और क्लस्टर किए गए अनुक्रमित के बारे में किम्बर्ली ट्रिप के पदों की समीक्षा करना चाह सकते हैं: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again.aspx!
मैं भी एक प्राकृतिक के बजाय इस मामले में एक सरोगेट कुंजी का सुझाव देता हूं।
यदि आपके पास कई-से-कई संबंधों का प्रतिनिधित्व करने वाली एक तालिका है जिसमें सिर्फ 2 कॉलम हैं, तो यह उचित लगता है।
सी एफ यह तो सवाल है
लेकिन मैं मानता हूं, कि मैं उन मामलों में भी सरोगेट कीज जोड़ता हूं।