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

Question

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

Answer 1

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

CREATE TABLE userdata (
  userid INT,
  userdataid INT,
  info char(200),
  primary key (userid, userdataid)
);

अद्यतन: यहाँ समग्र प्राथमिक कुंजियों के अधिक विस्तृत विवरण के साथ एक लिंक है ।

Comments

इस उदाहरण में, एक अद्वितीय पंक्ति को पहचानने / खोजने के लिए BOTH उपयोगकर्ता और userdataid की आवश्यकता होती है। ओपी की मंशा क्या थी, यह निश्चित नहीं है, लेकिन मैं यह देखने के लिए यहां आया था कि क्या मैं चाबी की एक पंक्ति के साथ विशिष्ट रूप से एक पंक्ति की पहचान कर सकता हूं। उदाहरण के लिए, मैं दोनों की आवश्यकता के बिना किसी उपयोगकर्ता नाम या उपयोगकर्ता नाम के साथ एक अद्वितीय उपयोगकर्ता की पहचान करना चाहूंगा। मुझे लगता है कि आरबी के अनोखे इंडेक्स का जवाब वहाँ की चाल होगा।

— बरटिटो

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

— 4AM

Answer 2

आपके पास केवल एक प्राथमिक कुंजी हो सकती है, लेकिन आपकी प्राथमिक कुंजी में कई कॉलम हो सकते हैं।

आपके पास अपनी तालिका पर अनन्य अनुक्रमणिकाएँ भी हो सकती हैं, जो प्राथमिक कुंजी की तरह थोड़ी सी काम करेंगी कि वे अद्वितीय मूल्यों को लागू करेंगी, और उन मूल्यों की क्वेरी को गति देंगी।

Answer 3

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

संबंधपरक डेटा मॉडल में उम्मीदवार कुंजी एक मौलिक अवधारणा है।

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

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

Comments

माना। तार्किक मॉडल में सभी कुंजी समान हैं (कोई भी 'प्राथमिक' नहीं है)। भौतिक कार्यान्वयन में किस कुंजी का चयन प्राथमिक कुंजी पदनाम को मध्यस्थता और विक्रेता / उत्पाद पर निर्भर करता है।

— onedaywhen

मैं कहूंगा कि यह डेटाबेस डिजाइनर पर निर्भर है।

— वाल्टर मिती

मैं अभी एक उपयोग के मामले में आया हूँ जहाँ यह आवश्यक है। मेरे पास एक टेबल है जो एंटिटी फ्रेमवर्क द्वारा बनाई / प्रबंधित की जाएगी - जो कि जहां तक ​​मैं इकट्ठा कर सकता हूं वह वर्तमान में गैर प्राथमिक प्रमुख अद्वितीय समग्र बाधाओं का समर्थन नहीं करता है। हालाँकि यह समग्र प्राथमिक कुंजी का समर्थन करता है। डेटा को एक दूरस्थ डेटाबेस सिस्टम से भी जोड़ा जा रहा है जो समग्र कुंजियों का समर्थन नहीं करता है। मैं EF में एक कंपोजिट पीके बनाने के साथ गया हूं, लेकिन एक गैर अशक्त GUID कॉलम भी जोड़ रहा हूं, जिसका उपयोग अन्य सिस्टम के खिलाफ विशिष्ट पहचान के लिए कर सकते हैं।

— क्रिस नेविल

क्रिस, मैंने कहा कि संबंधपरक मॉडल को प्राथमिक कुंजी की आवश्यकता नहीं है। मैंने इस बारे में कुछ नहीं कहा कि क्या कुछ उपकरण की आवश्यकता हो सकती है। लेकिन मैं आपकी बात लेता हूं।

— वाल्टर मिती

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

— गैरी

Answer 4

यह मुख्य प्रश्न और @ कालमी के प्रश्न के लिए दोनों का उत्तर है

कई ऑटो-जनरेट करने वाले कॉलम होने की बात क्या होगी?

नीचे दिए गए इस कोड में एक समग्र प्राथमिक कुंजी है। इसका एक कॉलम ऑटो-इंक्रीमेंटेड है। यह केवल MyISAM में काम करेगा। InnoDB एक त्रुटि उत्पन्न करेगा " ERROR 1075 (42000): गलत तालिका परिभाषा; केवल एक ऑटो कॉलम हो सकता है और इसे एक कुंजी के रूप में परिभाषित किया जाना चाहिए "।

DROP TABLE IF EXISTS `test`.`animals`;
CREATE TABLE  `test`.`animals` (
  `grp` char(30) NOT NULL,
  `id` mediumint(9) NOT NULL AUTO_INCREMENT,
  `name` char(30) NOT NULL,
  PRIMARY KEY (`grp`,`id`)
) ENGINE=MyISAM;

INSERT INTO animals (grp,name) VALUES
    ('mammal','dog'),('mammal','cat'),
    ('bird','penguin'),('fish','lax'),('mammal','whale'),
    ('bird','ostrich');

SELECT * FROM animals ORDER BY grp,id;

Which returns:

+--------+----+---------+
| grp    | id | name    |
+--------+----+---------+
| fish   |  1 | lax     |
| mammal |  1 | dog     |
| mammal |  2 | cat     |
| mammal |  3 | whale   |
| bird   |  1 | penguin |
| bird   |  2 | ostrich |
+--------+----+---------+

Comments

यह तब काम करता है जब आप प्राथमिक-मुख्य परिभाषा में पहले ऑटो-इंक्रीमेंट कॉलम को निर्दिष्ट करते हैं। (शायद यह बदल गया है, मैंने इसे केवल 5.6 में परीक्षण किया है)

— CTARczon

Answer 5

(इनका अध्ययन कर रहे हैं, बहुत कुछ)

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

• एक तालिका में कई उम्मीदवार कुंजी मौजूद हो सकती हैं।
  • प्राथमिक कुंजी - हमारे द्वारा चुनी गई उम्मीदवार कुंजियों में से केवल एक
  • वैकल्पिक कुंजी - अन्य सभी उम्मीदवार कुंजी
    • दोनों प्राथमिक कुंजी और वैकल्पिक कुंजी यौगिक कुंजी हो सकती हैं

स्रोत:
https://en.wikipedia.org/wiki/Superkey
https://en.wikipedia.org/wiki/Candidate_key
https://en.wikipedia.org/wiki/Primary_key
https://en.wikipedia.org / wiki / Compound_key

Answer 6

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

उदाहरण:

Person(id, name, email, street, zip_code, area)

बीच में एक कार्यात्मक निर्भरता हो सकती है id -> name,email, street, zip_code and area लेकिन अक्सर एक zip_codeके साथ जुड़ा हुआ है areaऔर इस प्रकार के बीच एक आंतरिक कार्यात्मक निर्भरता है zip_code -> area।

इस प्रकार कोई इसे दूसरी तालिका में विभाजित करने पर विचार कर सकता है:

Person(id, name, email, street, zip_code)
Area(zip_code, name)

ताकि यह तीसरे सामान्य रूप के अनुरूप हो ।

Answer 7

प्राथमिक कुंजी बहुत ही दुर्भाग्यपूर्ण संकेतन है, क्योंकि लॉजिकल मॉडल के साथ "प्राथमिक" और अवचेतन संघ के परिणामस्वरूप। मैं इस प्रकार इसका उपयोग करने से बचता हूं। इसके बजाय मैं भौतिक मॉडल के सरोगेट कुंजी और तार्किक मॉडल के प्राकृतिक कुंजी (ओं) को संदर्भित करता हूं।

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

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

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

ध्यान दें कि ये लाभ केवल तब होते हैं जब सरोगेट कुंजी छोटी और क्लस्टरिंग कुंजी दोनों होती है। यदि GUID को क्लस्टरिंग कुंजी के रूप में उपयोग किया जाता है, तो स्थिति अक्सर बदतर होगी यदि सबसे छोटी उपलब्ध प्राकृतिक कुंजी का उपयोग किया गया था। यदि तालिका को एक ढेर के रूप में व्यवस्थित किया जाता है, तो 8-बाइट (हीप) पंक्ति का उपयोग मुख्य लुकअप के लिए किया जाएगा, जो कि 16-बाइट वाले GUID से बेहतर है, लेकिन 4-बाइट पूर्णांक से कम परफ़ॉर्मेंट है।

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

यदि एक ढेर के परिणाम (हैश ज्वाइन हो जाते हैं) जो कि पसंदीदा स्टोरेज बनाते हैं, तो एक व्यापक क्लस्टरिंग कुंजी की लागत को व्यापार-बंद विश्लेषण में संतुलित करने की आवश्यकता होती है।

इस उदाहरण पर विचार करें ::

ALTER TABLE Persons
ADD CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

जहां टपल " (P_Id, LastName) " के लिए एक विशिष्ट अवरोध की आवश्यकता होती है, और एक यूनिकोड LastName प्लस 4-बाइट पूर्णांक हो सकता है, यह वांछनीय होगा (1) घोषित रूप से इस बाधा को " ADD CONSTRAINT pk_PersonID UNIQUE NCLE " के रूप में लागू किया जाएगा। , अंतिम नाम) "और (2) अलग से एक छोटे से सरोगेट कुंजी को घोषित क्लस्टर की" प्राथमिक कुंजी " घोषित करते हैं । यह ध्यान देने योग्य है कि अनीता संभवत: केवल इस अड़चन में लास्टनेम को जोड़ना चाहती है ताकि वह एक कवर फ़ील्ड, जो एक क्लस्टर इंडेक्स में अनावश्यक हो क्योंकि सभी फ़ील्ड इसके द्वारा कवर होते हैं।

भौतिक रूप से "पसंदीदा प्राकृतिक या उम्मीदवार कुंजी" (तार्किक मॉडल से) के अर्थ के साथ भौतिक रूप से "लुकिंग कुंजी" के अर्थ के एक टकराव के कारण गैर-क्रोधित के रूप में प्राथमिक कुंजी को नामित करने के लिए SQL सर्वर में क्षमता एक दुर्भाग्यपूर्ण ऐतिहासिक परिस्थिति है। नमूना। मेरी समझ यह है कि मूल रूप से SYBASE SQL सर्वर ने हमेशा फिजिकल मॉडल से "लुकअप कुंजी" के रूप में ढेर या क्लस्टर इंडेक्स में 4-बाइट पंक्ति का उपयोग किया है।

Comments

क्या आप कृपया इसे अंग्रेजी में अनुवाद कर सकते हैं!

— जसिर

Answer 8

कुछ लोग "प्राथमिक कुंजी" शब्द का उपयोग वास्तव में पूर्णांक स्तंभ का अर्थ करते हैं जो कुछ स्वचालित तंत्र द्वारा उत्पन्न अपने मूल्यों को प्राप्त करता है। उदाहरण के लिए AUTO_INCREMENTMySQL या IDENTITYMicrosoft SQL Server में। क्या आप इस अर्थ में प्राथमिक कुंजी का उपयोग कर रहे हैं?

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

mysql> create table foo (
  id int primary key auto_increment, 
  id2 int auto_increment
);
ERROR 1075 (42000): Incorrect table definition; 
there can be only one auto column and it must be defined as a key

डेटाबेस के कुछ अन्य ब्रांडों में, आप एक तालिका में एक से अधिक ऑटो-जनरेटिंग कॉलम को परिभाषित करने में सक्षम हैं।

Comments

कई ऑटो-जनरेट करने वाले कॉलम होने की बात क्या होगी?

— तर्ने कल्मन

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

— बिल कार्विन

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

— Nir

Answer 9

एक ही समय में दो प्राथमिक कुंजियाँ होना संभव नहीं है। लेकिन (यह मानते हुए कि आपने मामले को समग्र कुंजी के साथ गड़बड़ नहीं किया है), हो सकता है कि आपको एक विशेषता को अद्वितीय बनाने की आवश्यकता हो।

CREATE t1(
c1 int NOT NULL,
c2 int NOT NULL UNIQUE,
...,
PRIMARY KEY (c1)
);

हालाँकि, ध्यान दें कि रिलेशनल डेटाबेस में 'सुपर की' विशेषताओं का एक सबसेट है, जो एक तालिका में विशिष्ट रूप से एक टूपल या पंक्ति को पहचानता है। एक 'कुंजी' एक 'सुपर की' है जिसमें एक अतिरिक्त संपत्ति है जो कुंजी से किसी भी विशेषता को हटाती है, वह कुंजी को 'सुपर कुंजी' (या बस 'कुंजी' एक न्यूनतम सुपर कुंजी) बनाती है। यदि अधिक चाबियाँ हैं, तो वे सभी उम्मीदवार कुंजी हैं। हम प्राथमिक कुंजी के रूप में एक उम्मीदवार कुंजी का चयन करते हैं। यही कारण है कि एक संबंध या तालिका के लिए कई प्राथमिक कुंजी के बारे में बात करना एक संघर्ष है।

Comments

विकिपीडिया में 'कुंजी' की परिभाषा नहीं है। इसके अलावा, "कुंजी से किसी भी विशेषता को हटाने, उस कुंजी को कोई 'सुपर कुंजी' नहीं बनाता है" मेरे लिए कुछ भी मतलब नहीं था, क्योंकि सुपर कुंजी से एक विशेषता को हटाने पर अभी भी सुपर कुंजी हो सकती है।

— मनोहर रेड्डी पोरेड्डी

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

— रस्सिरू आदित्य समरसिंघे

ऐसा लगता है, 'कुंजी' का आपका वास्तविक अर्थ है Candidate_key ( en.wikipedia.org/wiki/Candidate_key ), यह उल्लेख किया जाना चाहिए।

— मनोहर रेड्डी Poreddy

@ManoharReddyPoreddy हां मैंने पहले ही अपने उत्तर में इसका उल्लेख किया है। "यदि अधिक चाबियाँ हैं, तो वे सभी उम्मीदवार कुंजी हैं"। वैसे भी आपकी समीक्षा के लिए धन्यवाद।

— रुसिरु आदित्य समरसिंघ

1. जब आप उल्लेख करते हैं "यदि अधिक चाबियाँ हैं, तो उनमें से सभी उम्मीदवार कुंजी हैं", ... क्या आपका मतलब है अन्यथा, अन्यथा, वे उम्मीदवार कुंजी नहीं हैं? ... 2. अन्य भाग कहाँ है? ... क्या हम एक ही पृष्ठ हैं?

— मनोहर रेड्डी पोरेड्डी

Answer 10

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

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

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

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

Answer 11

जितना मैं कर सकता हूं उससे बेहतर तकनीकी उत्तर दिए गए थे। मैं केवल इस विषय को जोड़ सकता हूं:

यदि आप ऐसा कुछ चाहते हैं जो अनुमति नहीं है / स्वीकार्य नहीं है तो यह कदम वापस लेने का अच्छा कारण है।

1. क्यों यह स्वीकार्य नहीं है के मूल को समझें।
2. प्रलेखन / पत्रिका लेख / वेब और आदि में अधिक खोदें
3. वर्तमान डिजाइन का विश्लेषण / समीक्षा करें और बड़ी खामियों को इंगित करें।
4. नए डिजाइन के दौरान हर कदम पर विचार और परीक्षण करें।
5. हमेशा आगे देखें और अनुकूली समाधान बनाने की कोशिश करें।

आशा है कि यह किसी की मदद करेगा।

Comments

सामान्य (हालांकि उपयोगी) सलाह, विशिष्ट प्रश्न का उत्तर नहीं।

— ब्रैडफोर्ड

Answer 12

हाँ, एसक्यूएल में यह संभव है, लेकिन हम MsAccess में एक से अधिक प्राथमिक कुंजी सेट नहीं कर सकते। फिर, मैं अन्य डेटाबेस के बारे में नहीं जानता।

CREATE TABLE CHAPTER (
    BOOK_ISBN VARCHAR(50) NOT NULL,
    IDX INT NOT NULL,
    TITLE VARCHAR(100) NOT NULL,
    NUM_OF_PAGES INT,
    PRIMARY KEY (BOOK_ISBN, IDX)
);

Comments

SQL टेबल में केवल एक PK हो सकता है।

— शाम