2010-09-29 24 views
18

Primary key और unique Key constraint के बीच क्या अंतर है?प्राथमिक कुंजी और अद्वितीय कुंजी बाधा के बीच क्या अंतर है?

इसका क्या उपयोग है ??

+0

क्या आप कुंजी और बाधा (पीके और अद्वितीय बाधा) या पीके बाधा और ब्रिटेन की बाधा के बीच अंतर के बारे में पूछ रहे हैं? –

उत्तर

11

दोनों का उपयोग तालिका के लिए candidate keys को इंगित करने के लिए किया जाता है।

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

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

डिफ़ॉल्ट रूप से SQL सर्वर में प्राथमिक कुंजी क्लस्टर सूचकांक बन जाएगी यदि यह ढेर पर बनाई गई है लेकिन यह अनिवार्य नहीं है कि पीके और क्लस्टर सूचकांक समान होना चाहिए।

+0

"डिफ़ॉल्ट रूप से SQL सर्वर में प्राथमिक कुंजी क्लस्टर सूचकांक बन जाएगी यदि यह ढेर पर बनाई गई है" का क्या मतलब है? –

+2

@ vgv8 - एक ढेर क्लस्टर सूचकांक के बिना एक टेबल है। यदि आप एक ही ढेर पर 'वैकल्पिक तालिका dbo.tbl ADD CONSTRAINT PKNAME प्राथमिक कुंजी (foo) चलाते हैं तो यह सूचकांक की कुंजी के साथ पीके कॉलम होने के साथ क्लस्टर्ड इंडेक्स बनाएगा। यदि तालिका में पहले से क्लस्टर्ड इंडेक्स है तो यह एक गैर क्लस्टर अद्वितीय इंडेक्स बनाएगा। –

+0

आह, यह कहना अधिक समझदार होता कि क्लस्टर्ड इंडेक्स केवल टेबल पर ही हो सकता है और यदि पीके बनने पर अभी तक कोई क्लस्टर्ड इंडेक्स नहीं था तो पीके को क्लस्टर्ड बनाया गया था (तालिका क्लस्टर, गैर-ढीला बनाकर) अन्यथा पीके गैर-क्लस्टर बनाया गया है। उत्तर में आपका वाक्यांश संदिग्ध था क्योंकि सूचकांक, क्लस्टर या गैर-क्लस्टर, बी-पेड़ में हमेशा (बनाए गए) होते हैं, यह वास्तविक तालिका डेटा ढेर पर हो सकता है यदि यह डेटा गैर-क्लस्टर हो। क्या मैं इसे गलत समझता हूँ? –

4

प्राथमिक कुँजी:

  1. प्राथमिक कुंजी कुछ भी नहीं है, लेकिन यह विशिष्ट एक तालिका में प्रत्येक पंक्ति को पहचानती है।

  2. प्राथमिक कुंजी डुप्लिकेट मानों की अनुमति नहीं देती है, न ही NULL

  3. डिफ़ॉल्ट रूप से प्राथमिक कुंजी क्लस्टर सूचकांक है।

  4. एक तालिका में केवल एक प्राथमिक कुंजी हो सकती है।

अद्वितीय कुंजी:

  1. अद्वितीय कुंजी कुछ भी नहीं है, लेकिन यह विशिष्ट एक तालिका में प्रत्येक पंक्ति को पहचानती है।

  2. अद्वितीय कुंजी डुप्लिकेट मानों की अनुमति नहीं देती है, लेकिन यह NULL को अनुमति देती है।

  3. डिफ़ॉल्ट रूप से अनन्य कुंजी एक गैर-क्लस्टर सूचकांक है।

यह समझने के लिए प्राथमिक कुंजीDatabase Keys. ध्यान रखें कि हम एक तालिका में केवल एक क्लस्टर सूचकांक एक फल पूरा लिंक है [SQL सर्वर 2005 के बारे में बात]। अब यदि हम एक और अद्वितीय कॉलम जोड़ना चाहते हैं तो हम अनन्य कुंजी कॉलम का उपयोग करेंगे, क्योंकि अद्वितीय कुंजी कॉलम को एक से अधिक जोड़ा जा सकता है।

+5

"कुछ भी नहीं" से आपका क्या मतलब है? –

7

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

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

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

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

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

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

  2. लुकअप की गति। मुख्य दक्षता महत्वपूर्ण हो सकती है, क्योंकि JOIN एस में कई WHERE क्लॉज और (अधिकतर) में उपयोग किया जाता है। विशेष रूप से JOINS के साथ, लुकअप की गति महत्वपूर्ण हो सकती है। प्रभाव कार्यान्वयन के विवरण पर निर्भर करेगा, और अलग-अलग डेटाबेस अलग-अलग डेटाटाइप को कैसे संभालेंगे इसके अनुसार अलग-अलग होंगे (पोस्टग्रेज़ में प्राथमिक कुंजी के रूप में टेक्स्ट के बड़े टुकड़े का उपयोग करने में प्रदर्शन प्रदर्शन से कुछ योग्यताएं होंगी, जहां मैं इसका उपयोग निर्दिष्ट कर सकता हूं हैश जुड़ता है, लेकिन मैं SQLServer में ऐसा करने में बहुत संकोच करता हूं [संपादित करें: "बड़े" के लिए मैं शायद उपयोगकर्ता नाम के आकार के बारे में सोच रहा हूं, पूरे नोर्स एडडास का आकार कुछ नहीं!])।

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

1

लघु संस्करण:

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

तो "प्राथमिक कुंजी" के रूप में एक अनूठी कुंजी को अलग करना केवल एक कार्यान्वयन सुविधा है (लेकिन एक महत्वपूर्ण एक)।

+0

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

+0

@ जोन हन्ना: डेटाबेस सिद्धांत में एक उम्मीदवार कुंजी में शून्य मान नहीं हो सकते हैं। "अद्वितीय कुंजी" शब्द एक ट्यूटोलॉजी और/या एक गलत नामक है। सभी चाबियाँ अनूठी हैं और चाबियां भी कमजोर नहीं हैं, लेकिन अगर हम इस अर्थ में "अद्वितीय" को SQL-style unqiue * बाधा * के संदर्भ में समझते हैं, तो हम उस चीज़ के बारे में बात कर रहे हैं जिसमें नल शामिल हो सकते हैं और इसलिए "कुंजी" नहीं है बिलकुल! इसलिए "अद्वितीय कुंजी" को "उम्मीदवार कुंजी" के रूप में समझा जाता है तो स्लेस्के सही है। मैं पूरी तरह से "अद्वितीय कुंजी" शब्द से परहेज करने की सिफारिश करता हूं। यह गलत व्याख्या करने के लिए बहुत खुला है। – sqlvogel

+0

@ डपोर्ट्स, नहीं क्योंकि कोई कुंजी कुछ पंक्तियों को शून्य से कवर नहीं कर सकती है। –

3

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

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

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

0

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

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

प्राथमिक कुंजी बाधा और अद्वितीय कुंजी बाधा के बीच अंतर?

1. एक तालिका केवल एक प्राथमिक कुंजी हो सकता है, लेकिन एक से अधिक अद्वितीय कुंजी

2. प्राथमिक कुंजी Nulls, जहां के रूप में अद्वितीय कुंजी एक अशक्त

ALTER TABLE Table_Name 
ADD CONSTRAINT Constraint_Name PRIMARY KEY (Column_Name) 

Alter Table Table_Name 
Add Constraint Constraint_Name Unique(Column_Name) 
की अनुमति देता है की अनुमति नहीं है
संबंधित मुद्दे