प्राथमिक कुंजी या विशिष्ट सूचकांक?

Question

काम पर हमारे पास प्राथमिक कुंजी के बजाय अद्वितीय अनुक्रमित के साथ एक बड़ा डेटाबेस है और सभी ठीक काम करते हैं।

मैं नए प्रोजेक्ट के लिए नया डेटाबेस डिजाइन कर रहा हूं और मुझे एक दुविधा है:

DB सिद्धांत में, प्राथमिक कुंजी मौलिक तत्व है, यह ठीक है, लेकिन वास्तविक परियोजनाओं में दोनों के फायदे और नुकसान क्या हैं?

आप परियोजनाओं में क्या उपयोग करते हैं?

संपादित करें: ... और MS SQL सर्वर पर प्राथमिक कुंजियों और प्रतिकृति के बारे में क्या?

Comments

यहाँ कुछ अतिरिक्त विचार-विमर्श किया गया है (एक आवरण सूचकांक के अतिरिक्त संदर्भ के साथ) - dba.stackexchange.com/questions/21554/…

— स्टुअर्टएलसी

नोट: SQLite इस मायने में भिन्न है कि वे विरासत की समस्या के कारण प्राथमिक कुंजी को सामान्य मानक के विपरीत होने देते हैं। sqlite.org/lang_createtable.html

— बिटिन

Answer 1

एक अद्वितीय सूचकांक क्या है?

स्तंभ पर एक अद्वितीय सूचकांक उस स्तंभ पर एक सूचकांक है जो बाधा को भी लागू करता है कि आप दो अलग-अलग पंक्तियों में उस स्तंभ में दो समान मान नहीं रख सकते। उदाहरण:

टेबल टेबल 1 (फू इंट, बार इंट);
तालिका 1 (फू) पर UNIQUE INDEX ux_table1_foo बनाएं; - फू पर अद्वितीय सूचकांक बनाएँ।

INSERT INTO table1 (फू, बार) VALUES (1, 2); -- ठीक है
INSERT INTO table1 (फू, बार) VALUES (2, 2); -- ठीक है
INSERT INTO table1 (फू, बार) VALUES (3, 1); -- ठीक है
INSERT INTO table1 (फू, बार) VALUES (1, 4); - विफल!

कुंजी 'ux_table1_foo' के लिए डुप्लिकेट प्रविष्टि '1'

अंतिम प्रविष्टि विफल हो जाती है क्योंकि यह स्तंभ पर अनन्य अनुक्रमणिका का उल्लंघन करता है fooजब वह दूसरी बार इस स्तंभ में मान 1 सम्मिलित करने का प्रयास करता है।

MySQL में एक अनूठा अवरोध कई NULLs को अनुमति देता है।

म्यूटेंट कॉलम पर एक अद्वितीय सूचकांक बनाना संभव है।

प्राथमिक कुंजी बनाम अद्वितीय सूचकांक

चीजें जो समान हैं:

• एक प्राथमिक कुंजी का अर्थ है एक अद्वितीय सूचकांक।

चीजें जो अलग हैं:

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

Comments

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

— एलेक्स जैस्मिन

@Alexandre जैस्मीन: फिक्स्ड धन्यवाद। बाद में कई कॉलमों के बारे में बताया गया है।

— मार्क बायर्स

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

— डेविड एल्ड्रिज

लेकिन फिर भी मुझे यह नहीं मिला, जैसे प्राथमिक कुंजी का उपयोग कब करना है या अद्वितीय सूचकांक का उपयोग कब करना है? या दोनों एक ही स्थिति में हो सकते हैं।

— अमित

Answer 2

आप इसे इस तरह देख सकते हैं:

एक प्राथमिक कुंजी अद्वितीय है

एक विशिष्ट मूल्य तत्व का प्रतिनिधि नहीं होना चाहिए

मतलब ?; वैसे तत्व की पहचान करने के लिए एक प्राथमिक कुंजी का उपयोग किया जाता है, यदि आपके पास एक "व्यक्ति" है तो आप एक व्यक्तिगत पहचान संख्या (एसएसएन या ऐसी) चाहते हैं जो आपके व्यक्ति के लिए प्राथमिक हो।

दूसरी ओर, व्यक्ति के पास एक ई-मेल हो सकता है जो अद्वितीय है, लेकिन व्यक्ति की पहचान नहीं करता है।

मेरे पास हमेशा प्राथमिक कुंजी होती है, यहां तक ​​कि रिश्ते की तालिकाओं (मध्य-तालिका / कनेक्शन तालिका) में भी हो सकता है। क्यों? वैसे मुझे कोडिंग करते समय एक मानक का पालन करना पसंद है, यदि "व्यक्ति" के पास एक पहचानकर्ता है, तो कार में एक पहचानकर्ता है, ठीक है, फिर व्यक्ति -> कार में एक पहचानकर्ता भी होना चाहिए!

Comments

अपने रिश्ते की तालिकाओं में: क्या आपका मतलब है कि आप एक कृत्रिम प्राथमिक कुंजी (उदाहरण के लिए पूर्णांक) के साथ एक नया स्तंभ पेश करते हैं या आप एक प्राथमिक प्राथमिक कुंजी (person_id, car_id) का उपयोग करते हैं?

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

— फिलिप एकबर्ग

दूसरी चीज जो सरोगेट प्राइमरी की है, वह आपके कंपोजिट / जॉइन टेबल के लिए है, यह मैनुअल टास्क के रखरखाव में आसान है।

— रॉबर्ट सी। बर्थ

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

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

Answer 3

विदेशी कुंजी अद्वितीय बाधाओं के साथ-साथ प्राथमिक कुंजी के साथ काम करती है। ऑनलाइन पुस्तकों से:

एक पूर्व कुंजी की बाधा को केवल एक अन्य तालिका में एक प्राथमिक कुंजी बाधा से जोड़ा जाना नहीं है; इसे एक अन्य तालिका में एक UNIQUE बाधा के स्तंभों को संदर्भित करने के लिए भी परिभाषित किया जा सकता है

लेन-देन प्रतिकृति के लिए, आपको प्राथमिक कुंजी की आवश्यकता है। ऑनलाइन पुस्तकों से:

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

दोनों उत्तर SQL Server 2005 के लिए हैं।

Comments

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

Answer 4

प्राकृतिक कुंजी के विपरीत सरोगेट प्राथमिक कुंजी का उपयोग कब करना है इसका विकल्प मुश्किल है। हमेशा या कभी नहीं जैसे जवाब, शायद ही कभी उपयोगी होते हैं। मुझे लगता है कि यह स्थिति पर निर्भर करता है।

एक उदाहरण के रूप में, मेरे पास निम्न तालिकाएँ हैं:

CREATE TABLE toll_booths (
    id            INTEGER       NOT NULL PRIMARY KEY,
    name          VARCHAR(255)  NOT NULL,
    ...
    UNIQUE(name)
)

CREATE TABLE cars (
    vin           VARCHAR(17)   NOT NULL PRIMARY KEY,
    license_plate VARCHAR(10)   NOT NULL,
    ...
    UNIQUE(license_plate)
)

CREATE TABLE drive_through (
    id            INTEGER       NOT NULL PRIMARY KEY,
    toll_booth_id INTEGER       NOT NULL REFERENCES toll_booths(id),
    vin           VARCHAR(17)   NOT NULL REFERENCES cars(vin),
    at            TIMESTAMP     DEFAULT CURRENT_TIMESTAMP NOT NULL,
    amount        NUMERIC(10,4) NOT NULL,
    ...
    UNIQUE(toll_booth_id, vin)
)

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

http://database-programmer.blogspot.com के इस विशेष विषय पर कुछ बेहतरीन लेख हैं।

Answer 5

प्राथमिक कुंजी का कोई नुकसान नहीं हैं।

@MrWiggles और @Peter पार्कर के जवाबों के लिए बस कुछ जानकारी जोड़ने के लिए, जब तालिका में प्राथमिक कुंजी नहीं होती है, उदाहरण के लिए आप कुछ अनुप्रयोगों में डेटा संपादित नहीं कर पाएंगे (वे यह कहते हुए समाप्त हो जाएंगे जैसे sth संपादित नहीं कर सकते / बिना डेटा हटा सकते हैं प्राथमिक कुंजी)। Postgresql कई NULL मान UNIQUE कॉलम में होने देता है, PRIMARY KEY NULLs को अनुमति नहीं देता है। इसके अलावा कुछ ओआरएम जो कोड उत्पन्न करते हैं उनमें प्राथमिक कुंजी के बिना तालिकाओं के साथ कुछ समस्याएं हो सकती हैं।

अपडेट करें:

जहां तक ​​मुझे पता है कि MSSQL में प्राथमिक कुंजी के बिना तालिकाओं को दोहराने के लिए संभव नहीं है, कम से कम समस्याओं ( विवरण ) के बिना ।

Comments

जब नई पंक्तियाँ डाली जाती हैं या स्तंभ अद्यतन किया जाता है तो ओवरहेड होता है।

Answer 6

यदि कोई चीज़ प्राथमिक कुंजी है, तो आपके DB इंजन के आधार पर, पूरी तालिका प्राथमिक कुंजी द्वारा क्रमबद्ध हो जाती है। इसका मतलब यह है कि प्राथमिक कुंजी पर लुकअप बहुत तेजी से होता है क्योंकि इसमें किसी भी प्रकार की डीफ्रेंसिंग नहीं करनी होती है क्योंकि इसे किसी अन्य प्रकार के इंडेक्स के साथ करना होता है। इसके अलावा, यह सिर्फ सिद्धांत है।

Comments

तालिका को प्राथमिक कुंजी द्वारा neccesately क्लस्टर किए गए सूचकांक द्वारा क्रमबद्ध किया जाएगा।

— रे बोयसेन

यह सिर्फ इतना होता है कि अधिकांश लोग क्लस्टर इंडेक्स होने के लिए अपनी प्राथमिक कुंजी सेट करते हैं।

— रे बोयसेन

जो हम जानते हैं कि अक्सर एक बहुत बुरा विचार होता है, जब तक कि हम अपनी मेजों में गर्म-धब्बों और असंतुलित सूचकांक वाले पेड़ों को पसंद नहीं करते, निश्चित रूप से ...

— माइक वुडहाउस

यह हमेशा एक बहुत बुरा विचार नहीं है। अपने डेटा को जानें, अपने RDBMS को जानें, जानें कि विकल्पों का क्या मतलब है। शायद ही कभी अच्छा या बुरा विकल्प होता है। यदि हमेशा एक था, तो डेटाबेस इसे अनिवार्य कर देगा या इसे अस्वीकृत कर देगा। वे आपको विकल्प देते हैं क्योंकि 'यह निर्भर करता है।'

Answer 7

अन्य उत्तरों ने जो कहा है, इसके अलावा, कुछ डेटाबेस और सिस्टम को उपस्थित होने के लिए एक प्राथमिक की आवश्यकता हो सकती है । एक स्थिति मन में आती है; Informix के साथ एंटरप्राइज़ प्रतिकृति का उपयोग करते समय प्रतिकृति में भाग लेने के लिए एक तालिका के लिए एक PK मौजूद होना चाहिए।

Answer 8

जब तक आप NULL को एक मान के लिए अनुमति नहीं देते हैं, तब तक उन्हें एक ही संभाला जाना चाहिए, लेकिन NULL को डेटाबेस पर अलग तरीके से संभाला जाता है (AFAIK MS-SQL एक से अधिक अनुमति नहीं देते हैं (1) NULL मान, mySQL और Oracle इसकी अनुमति देते हैं , अगर कोई कॉलम UNIQUE है) तो आपको इस कॉलम को NOT NULL UNIQUE INDEX को परिभाषित करना होगा

Comments

MS-SQL एक स्तंभ में कई NULL मानों की अनुमति देता है जिसमें एक अद्वितीय सूचकांक होता है, जैसा कि हर RDBMS को होना चाहिए। इसे इस तरह से सोचें: NULL का कोई मूल्य नहीं है, इसलिए जब आप दूसरा NULL डालें, तो यह कभी भी किसी मौजूदा से मेल नहीं खाएगा। अभिव्यक्ति (NULL == NULL) सही या गलत के लिए विकसित नहीं होती है, यह NULL का मूल्यांकन करती है।

— ग्रागमेक

thanx gregmac, मुझे यकीन नहीं था, अगर MS इसका अनुसरण करता है। मुझे इसके साथ कुछ MS Quirks याद आए, हालाँकि कुछ साल पहले (2000 से पहले) और एक पुरानी पहुँच हो सकती है-DB खांसी

— पीटर पार्कर

Answer 9

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

यूनिक इंडेक्स SQL ​​मानक का हिस्सा नहीं हैं। एक डीबीएमएस का विशेष कार्यान्वयन यह निर्धारित करेगा कि एक अद्वितीय सूचकांक घोषित करने के परिणाम क्या हैं।

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

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

Comments

MS SQL सर्वर में एक प्राथमिक कुंजी हमेशा UNIQUE और NOT NULL दोनों होती है - जैसे कि यह वास्तव में सिर्फ एक अद्वितीय सूचकांक है, लेकिन अतिरिक्त प्रतिबंध के साथ कि यह NULL नहीं हो सकता है।

— marc_s

ओरेकल एक गैर-अद्वितीय सूचकांक के साथ एक अद्वितीय बाधा को लागू कर सकता है। मुझे आश्चर्य होगा अगर MSSS नहीं कर सका। यह कहना कि "यह वास्तव में सिर्फ एक अद्वितीय सूचकांक है" एक असंतोष है।

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

— JAC2703

ओपी ने गोदामों का उल्लेख नहीं किया। मुझे यकीन नहीं है कि हैश sql सर्वर पर कैसे काम करता है। वेयरहाउस अपडेट के समय में कितना काम किया जा सकता है।

— वाल्टर मिटी

Answer 10

CLICKERED INDEXES बनाम UNIQUE INDEXES के कुछ नुकसान हैं।

जैसा कि पहले ही कहा गया है, एक अनुमानित सूचकांक शारीरिक रूप से तालिका में डेटा का आदेश देता है।

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

सापेक्ष छोटी तालिकाओं में, यह ठीक है, लेकिन जब उन तालिकाओं को प्राप्त करना होता है जिनमें जीबी के डेटा का मूल्य होता है, और आवेषण / हटाने छँटाई को प्रभावित करते हैं, तो आप समस्याओं में भाग लेंगे।

Comments

फिर क्या फायदा? हल किए गए प्रश्न तेजी से हैं? क्या यह उपयोग-मामले के लिए बेहतर है जब आप अपना अधिकांश डेटा एक बार (या शायद ही कभी) लिखते हैं और इसे हर समय क्वेरी करते हैं?

— भैंस

Answer 11

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

जब मैं एक सरोगेट कुंजी नहीं बनाता तो कुछ समय होता है जब मेरे पास एक ज्वाइनिंग टेबल होती है जो कई-कई संबंधों में शामिल होती है। इस मामले में मैं दोनों क्षेत्रों को प्राथमिक कुंजी घोषित करता हूं।

Comments

"मैं लगभग एक संख्यात्मक प्राथमिक कुंजी के बिना एक तालिका कभी नहीं बनाता हूं": हमेशा संख्यात्मक क्यों? एक प्राथमिक कुंजी को संख्यात्मक होने की आवश्यकता नहीं है (न तो इसे AUTO_INCREMENT होने की आवश्यकता है)।

— हिब्बू57

@ Hinou57, क्योंकि मैंने पाया है कि प्राकृतिक कुंजी शायद ही कभी अद्वितीय होती है और वे लगभग हमेशा परिवर्तनशील होती हैं। अंतर पर फरहारे जोड़ आम तौर पर वर्चहर प्राकृतिक कुंजियों या बदतर समग्र कुंजियों में जुड़ने की तुलना में बहुत तेज होते हैं। मैं उन्हें समय का अधिकतम उपयोग नहीं करेंगे। यह आपके डेटाबेस में आपके द्वारा संग्रहीत जानकारी के प्रकार में भिन्न हो सकता है, लेकिन मेरे व्यक्तिगत अनुभव में मुझे समय के साथ बेहद अविश्वसनीय होने के लिए प्राकृतिक कुंजी मिली है।

— HLGEM

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

— हिबू

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

— HLGEM

Answer 12

मेरी समझ यह है कि प्राथमिक कुंजी और एक अद्वितीय सूचकांक जिसमें ra अशक्त बाधा नहीं है, वही (*) हैं; और मुझे लगता है कि विनिर्देश स्पष्ट रूप से बताता है या निहित है (क्या आप व्यक्त करना चाहते हैं और स्पष्ट रूप से लागू करना चाहते हैं) के आधार पर एक या एक का चयन करें। यदि इसे विशिष्टता की आवश्यकता है और requires अशक्त नहीं है, तो इसे एक प्राथमिक कुंजी बनाएं। यदि यह सिर्फ होता है एक अद्वितीय सूचकांक के सभी भागों that के लिए किसी भी आवश्यकता के बिना अशक्त नहीं हैं, तो बस इसे एक अद्वितीय सूचकांक बनाते हैं।

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

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

यहां अन्य लोगों ने डीबी प्रतिकृति का उल्लेख किया है, लेकिन मुझे इसके बारे में पता नहीं है।

Answer 13

यूनिक इंडेक्स में एक NULL वैल्यू हो सकती है। यह NON-CLUSTERED INDEX बनाता है। प्राथमिक कुंजी में पूर्ण मान नहीं हो सकता। यह CLUSTERED INDEX बनाता है।

Answer 14

MSSQL में, प्राथमिक कुंजियाँ क्लस्टर इंडेक्स पर सर्वश्रेष्ठ प्रदर्शन के लिए एकरूपता से बढ़नी चाहिए। इसलिए पहचान सम्मिलित करने के साथ एक पूर्णांक किसी भी प्राकृतिक कुंजी से बेहतर होता है जो शायद एकतरफा वृद्धि नहीं हो सकती है।

Answer 15

अगर यह मेरे वश में होता...

आपको डेटाबेस और अपने अनुप्रयोगों की आवश्यकताओं को पूरा करने की आवश्यकता है।

प्राथमिक कुंजी के रूप में सेवा करने के लिए हर मेज पर एक ऑटो-इंक्रीमेंटिंग पूर्णांक या लंबी आईडी कॉलम जोड़ना डेटाबेस आवश्यकताओं का ख्याल रखता है।

फिर आप अपने अनुप्रयोग द्वारा उपयोग के लिए तालिका में कम से कम एक अन्य अद्वितीय सूचकांक जोड़ेंगे। यह कर्मचारी_आईडी, या अकाउंट_आईडी, या ग्राहक_आईडी, आदि पर सूचकांक होगा। यदि संभव हो तो, यह सूचकांक एक समग्र सूचकांक नहीं होना चाहिए।

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

मैं परिकलित या फ़ंक्शन प्रकार सूचकांकों का उपयोग करने के लिए हूं - और समग्र सूचकांकों पर उनका उपयोग करने की सलाह दूंगा। यह आपके जहां क्लॉज में समान फ़ंक्शन का उपयोग करके फ़ंक्शन इंडेक्स का उपयोग करना बहुत आसान बनाता है।

यह आपकी एप्लिकेशन आवश्यकताओं का ध्यान रखता है।

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