प्राथमिक कुंजी (समग्र प्राथमिक कुंजी) के रूप में कई कॉलमों का उपयोग क्यों करें

109

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

मेरी समझ यह है कि दोनों कॉलम ( P_Idऔर LastName) तालिका के लिए एक प्राथमिक कुंजी का प्रतिनिधित्व करते हैं Persons। क्या ये सही है?

कोई एकल स्तंभ के बजाय प्राथमिक स्तंभ के रूप में एकाधिक स्तंभों का उपयोग क्यों करना चाहेगा?
दी गई तालिका में प्राथमिक कुंजी के रूप में एक साथ कितने स्तंभों का उपयोग किया जा सकता है?

— rockbala
स्रोत

... अब 2'और प्रश्न का

— वुल्फ

1

@ मर्तिजन पीटर्स। उत्तर क्यों हटाया गया?

— प्रदर्शन

119

आपकी समझ सही है।

आप कई मामलों में ऐसा करेंगे। एक उदाहरण एक रिश्ते में है जैसे OrderHeaderऔर OrderDetail। पीके OrderHeaderहो सकता है OrderNumber। पी में OrderDetailहो सकता है OrderNumberऔर LineNumber। यदि यह उन दोनों में से एक था, तो यह अद्वितीय नहीं होगा, लेकिन दोनों के संयोजन की गारंटी अद्वितीय है।

विकल्प इस मामले में उदाहरण के लिए, एक उत्पन्न (गैर-बुद्धिमान) प्राथमिक कुंजी का उपयोग करना है OrderDetailId। लेकिन तब आप रिश्ते को हमेशा आसानी से नहीं देख पाएंगे। कुछ लोग एक तरह से पसंद करते हैं; कुछ दूसरे तरीके को पसंद करते हैं।

— MJB
स्रोत

2

क्या यह उपयोगी है अगर मैं ब्रांच_आईडी का उपयोग कर रहा हूं और दो डेटाबेस के बीच प्रतिकृति का उपयोग कर रहा हूं, तो आईडी की डुप्लिकेट को हल करेगा?

— शाम

11

ध्यान दें कि उत्पन्न प्राथमिक कुंजी का उपयोग करने के कई मामलों में, आप अक्सर समग्र मूल्यों पर एक अनूठी कुंजी चाहते हैं।

— बेकन बिट्स

कृपया "कुछ लोग एक तरह से पसंद करते हैं, कुछ अन्य तरीके से पसंद करते हैं" पर विस्तार से बताएं।

— यूजरनेम

1

सुख विस्तृत? पता नहीं क्या कहूं। मैंने ऐसे लोगों को जाना है जो एक कुंजी के रूप में कई संक्षिप्त क्षेत्रों को पसंद करते हैं क्योंकि यह समझना आसान है कि वे क्या देख रहे हैं। मैंने अन्य लोगों को जाना है जो प्रत्येक पंक्ति में केवल एक अद्वितीय कुंजी निर्दिष्ट करना पसंद करते हैं क्योंकि यह टाइप करना आसान और तेज है। क्या आप जो पूछ रहे हैं?

— MJB

वह संदेश @Username के लिए था। मैं इसे निर्देशित करना भूल गया।

— MJB

26

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

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

— जॉन हार्टसॉक
स्रोत

महान व्याख्या: मुझे लगता है कि एम-टू-एन संबंधों (एक सामान्यीकृत आक्रमण में) के लिए विशेषताओं की आवश्यकता है।

— वुल्फ

शायद थोड़ा लाभ स्पष्टीकरण भी बेहतर होगा

— Martian2049

10

W3Schools का उदाहरण यह नहीं कह रहा है कि आपको कंपाउंड प्राइमरी कीज़ का उपयोग कब करना चाहिए, और सिर्फ़ एक उदाहरण तालिका का उपयोग करके सिंटैक्स दे रहा है जैसे कि अन्य कुंजियाँ।

उनकी पसंद का उदाहरण संभवतः एक व्यर्थ कुंजी (P_Id) और एक प्राकृतिक कुंजी (LastName) को मिलाकर आपको भ्रमित कर रहा है। प्राथमिक कुंजी का यह विषम विकल्प कहता है कि निम्न पंक्तियाँ स्कीमा के अनुसार मान्य हैं और किसी छात्र की विशिष्ट पहचान के लिए आवश्यक हैं। वास्तव में इसका कोई मतलब नहीं है।

1234     Jobs
1234     Gates

इसके अलावा पढ़ना: महान प्राथमिक-प्रमुख बहस या सिर्फ Google meaningless primary keysया यहां तक कि इस एसओ प्रश्न का दुरुपयोग

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

— रॉबर्ट पॉलसन
स्रोत

1

1) "महान प्राथमिक कुंजी बहस" लिंक विशेष रूप से बेवकूफ है, यह जानकारी स्वयं-सेवारत और झूठी है। 2) पंक्ति को विशिष्ट बनाने वाले स्तंभों पर अनुक्रमणिका को टाला नहीं जा सकता। एक इंडेक्स के साथ "सरोगेट" आईडी हमेशा एक अतिरिक्त कॉलम और एक अतिरिक्त इंडेक्स होता है। बल्कि मूर्खतापूर्ण है क्योंकि यह बेमानी है। और धीमा।

— प्रदर्शन

2

"महान प्राथमिक महत्वपूर्ण बहस" बेवकूफ नहीं है। यह डेवलपर्स से एक बहुत ही वैध मुद्दा है जो sql Developers या sql DBA नहीं हैं और अपना सारा समय sql में नहीं बिताते हैं। शुद्ध sql में भी, मैं प्राथमिक कुंजी के रूप में एक अर्थहीन ऑटो-जेनरेट की गई कुंजी होगी जब प्राकृतिक कुंजी होने के आसपास डेटा के n बिट्स को पास करने के लिए याद करने की तुलना में जुड़ना होगा। आप अपने दृष्टिकोण में आपका स्वागत करते हैं, लेकिन हम इस बात की सराहना करेंगे कि ऐसा न हो।

— रॉबर्ट पॉलसन

4

जब भी आप कई विशेषताओं के संयोजन की विशिष्टता को सुनिश्चित करना चाहते हैं आप एक यौगिक कुंजी (एक से अधिक विशेषताओं वाली कुंजी) का उपयोग करते हैं। एक एकल विशेषता कुंजी समान चीज़ को प्राप्त नहीं करेगी।

— nvogel
स्रोत

1

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

— जॉन मार्क

3

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

— ig0774
स्रोत

3

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

— HLGEM
स्रोत

1

1) प्रदर्शन। एसक्यूएल प्लेटफॉर्म में नहीं (शायद "एसक्यूएल" एस और फ्रीवेयर के नाटक में)। 2) वरीयता अप्रासंगिक है। अखंडता के लिए तालिकाओं की क्या आवश्यकता है, प्रासंगिक है। 3) एक इंडेक्स वाली "सरोगेट" आईडी हमेशा एक अतिरिक्त कॉलम और एक अतिरिक्त इंडेक्स होती है। ताकि किसी भी प्लेटफॉर्म पर यह धीमा हो। पुनः प्रदर्शन, आप अपने आप को विरोधाभासी। 4) यदि आप नहीं जानते कि 215 बच्चों की तालिकाओं में पौराणिक "मिलियन चाइल्ड एंट्रीज़" को ठीक से कैसे अपडेट किया जाए , तो एक प्रश्न पूछें।

— प्रदर्शनदिवस

2

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

— 19'19

3

आपका दूसरा प्रश्न

दी गई तालिका में प्राथमिक कुंजी के रूप में एक साथ कितने स्तंभों का उपयोग किया जा सकता है?

कार्यान्वयन विशिष्ट है: इसका उपयोग वास्तविक DBMS में परिभाषित किया जा रहा है। ^{[१], [२], [३]} आपको अपने द्वारा उपयोग किए जाने वाले डेटाबेस सिस्टम के तकनीकी विनिर्देश का निरीक्षण करना होगा। कुछ बहुत विस्तृत हैं, कुछ नहीं हैं। ऐसी सीमाओं के बारे में वेब खोजना कठिन हो सकता है क्योंकि शब्दावली बदलती है। शब्द समग्र प्राथमिक कुंजी अनिवार्य होना चाहिए;)

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

— भेड़िया
स्रोत

2

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

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

दूसरी तालिका "अक्षर" थी- नाम और संक्षिप्त विवरण। प्राथमिक कुंजी "charname" पर थी।

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

— मिस्टर इनिशियल मैन
स्रोत

1

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

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

— kiwicomb123
स्रोत