क्या एक टेबल पर एकाधिक प्राथमिक कुंजी मौजूद हो सकती हैं?

• कुंजी क्या हैं?
  • साधारण कुंजियाँ
  • संयोजित या मिश्रित कुंजियाँ
  • प्राथमिक कुंजी
    • संख्या और ऑटो-इन्क्रीमेंटिंग
• क्या किसी तालिका में एकाधिक प्राथमिक कुंजियाँ हो सकती हैं?

जबकि कई डेवलपर और डेटाबेस व्यवस्थापक primary keys . के साथ काम कर सकते हैं प्रतिदिन, स्वयं से यह पूछना एक आकर्षक विषय है, "वास्तव में क्या है एक primary key और डेटाबेस तालिका में एकाधिक primary keys हो सकती है (या चाहिए) एक साथ?"

नीचे हम इन सवालों की अधिक विस्तार से जांच करेंगे और विकास समुदाय के भीतर उचित और आम तौर पर सहमति पर आने का प्रयास करेंगे।

कुंजी क्या हैं?

यह समझने के लिए कि primary key क्या है एक डेटाबेस तालिका में है, हमें पहले non-primary keys के बारे में थोड़ा समझना चाहिए . एक key तालिका में केवल एक विशेषता है जिसका उपयोग उस जानकारी को पहचानने और उस तक पहुंचने के लिए किया जाता है। एक टेबल में और अक्सर कई कुंजियाँ हो सकती हैं, जैसे तालिका में Users दोनों email और username कुंजी माना जा सकता है।

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

साधारण कुंजियाँ

एक simple key तालिका में केवल एक एकल विशेषता का उपयोग करके केवल एक कुंजी है। जब तक हम कुंजी या तालिका पर अधिक प्रतिबंध नहीं लगाते हैं, तब तक username उपरोक्त उदाहरण में विशेषता एक simple key है ।

सम्मिलित या मिश्रित कुंजियाँ

simple keys से एक कदम आगे ले गए concatenated हैं या compound चांबियाँ। जैसा कि नाम से ही स्पष्ट है, एक concatenated key एकाधिक single keys का संयोजन है . उदाहरण के लिए, सिस्टम स्वचालित रूप से last_name . को जोड़ सकता है और year_of_birth single keys एक concatenated key . में , जैसे:smith1980 ।

प्राथमिक कुंजी

एक [primary key](https://en.wikipedia.org/wiki/Unique_key) एक कुंजी है जिसे प्रमुख (या प्राथमिक .) के रूप में चुना गया है ) डेटा की उस पंक्ति के लिए प्रतिनिधि विशेषता। primary key अद्वितीय है और उस विशेषता का तब पूरे डेटाबेस में उपयोग किया जाता है और इसे एक्सेस किया जाता है और अन्य तालिकाओं के आसपास प्रश्न में डेटा के लिए प्रतिनिधि विशेषता के रूप में पारित किया जाता है।

व्यवहार में, primary key विशेषता को NOT NULL के रूप में भी चिह्नित किया गया है अधिकांश डेटाबेस में, जिसका अर्थ है कि तालिका में रिकॉर्ड डालने के लिए विशेषता में हमेशा एक मान होना चाहिए।

उदाहरण के तौर पर, या तो email या username simple keys कर सकता था primary key . का पदनाम दिया जाए , लेकिन आमतौर पर primary key . सेट करना सबसे अच्छा अभ्यास है एक विशेषता के लिए जिसे व्यावसायिक तर्क या यहां तक ​​कि व्यक्ति द्वारा बदला नहीं जा सकता (या नहीं बदला जा सकता है)। उदाहरण के लिए, एक Users की कल्पना करें एक नया ईमेल पता प्राप्त करता है, जो तब सभी पिछले primary key . का कारण बनता है नए ईमेल पते का उपयोग करते समय अमान्य होने के लिए पुराने ईमेल पते का उपयोग करने वाले संघ।

इस कारण से (दूसरों के बीच), अधिकांश primary keys किसी संख्या या अद्वितीय स्ट्रिंग का उपयोग करें, जैसे कि [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) ।

Numeration and Auto-incrementing

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

उदाहरण के लिए, सभी Users . की कल्पना करें रिकॉर्ड्स को एक ऑटो-इन्क्रिमेंटेड primary key असाइन किया जाता है मान, id . के रूप में जानें गुण। यदि किसी दुर्भावनापूर्ण व्यक्ति को पता चलता है कि id किसी दिए गए उपयोगकर्ता (जैसे जॉन स्मिथ) की विशेषता मान 1500 . है , यह पहले से ही कुछ जानकारी को उजागर करता है। सबसे पहले, यह इंगित करता है कि सिस्टम में कम से कम 1499 अन्य उपयोगकर्ता होने की संभावना है, या किसी बिंदु पर थे। इसका अर्थ यह भी है कि यदि जॉन स्मिथ के उपयोगकर्ता पृष्ठ को URL या API कॉल के माध्यम से एक्सेस किया जा सकता है जिसमें वह id है 1500 . का मान , तो मान को किसी अन्य संख्या में बदलने का एक अच्छा मौका है, जैसे कि 1499 या 1501 , किसी अन्य उपयोगकर्ता के पृष्ठ को उजागर करेगा जो नहीं चाहता कि उसका पृष्ठ इस आगंतुक द्वारा एक्सेस किया जाए। इस प्रकार, रिकॉर्ड्स को केवल अनुमान लगाकर . द्वारा क्वेरी किया जा सकता है id बड़े पैमाने पर मान।

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

क्या किसी तालिका में अनेक प्राथमिक कुंजियाँ हो सकती हैं?

संक्षिप्त उत्तर नहीं . है , एक तालिका में एकाधिक primary keys शामिल करने की अनुमति नहीं है , क्योंकि यह संबंधपरक डेटाबेस डिज़ाइन के मूलभूत सिद्धांतों के विरुद्ध जाता है (देखें:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) और [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) )।

यह है एक टेबल के लिए कई candidate keys होना संभव है , जो प्रभावी रूप से primary key . के समान व्यवहार करता है उसमें एक candidate key अद्वितीय है, NOT NULL , और उस तालिका रिकॉर्ड का एक विलक्षण प्रतिनिधित्व है।

हालांकि, जब चुनने की बात आती है कि कौन सा एक विशेषता को primary key . के रूप में असाइन किया जाएगा तालिका के लिए, विकल्प सभी संभावित candidate keys . की सूची से आता है (इसलिए नाम, वे primary key . बनने के लिए उम्मीदवार हैं ) अंततः, केवल एक candidate key इस तालिका में primary key के रूप में उपयोग करने के लिए, उस रिकॉर्ड के लिए सर्वश्रेष्ठ प्रतिनिधि विशेषता के रूप में चुना गया है और उनके संबंधित foreign keys . के माध्यम से अन्य तालिकाओं द्वारा डेटाबेस में कहीं और संदर्भित ।