2011-12-06 14 views
5

मॉड पर ध्यान दें: मैंने इस मुद्दे से संबंधित लगभग एक दर्जन पदों को पढ़ा, लेकिन उनमें से कोई भी मेरे प्रश्न का उत्तर नहीं दिया। कृपया इस पोस्ट को हटाने के लिए ध्वजांकित न करें; यह एक डुप्लिकेट सवाल नहीं है।क्या MySQL को कई से अधिक लिंक टेबल के लिए प्राथमिक कुंजी की आवश्यकता है?

मैं एक वेब गैलरी के लिए डेटाबेस तैयार कर रहा हूं जिसमें कई से अधिक संबंध होंगे। उदाहरण के लिए, टैग और छवियां। जाहिर है, इसे पूरा करने के लिए एक तिहाई, लिंक, टेबल बनाया जाएगा। मैं टैग तालिका और छवि तालिका में प्राथमिक कुंजी कॉलम रखने के लिए उपयोग देख सकता हूं, लेकिन मैं लिंक तालिका में इसके लिए उपयोग की कल्पना नहीं कर सकता। यह सिर्फ सर्वर की जगह ले जाएगा। तो, मैं सिर्फ लिंक तालिका में प्राथमिक कुंजी कॉलम नहीं होने की सोच रहा हूं। क्या MySQL इसे अनुमति देता है? या, लिंक तालिका में प्राथमिक कुंजी रखने के लिए कोई अनिवार्य कारण होगा? धन्यवाद।

लिंक तालिका:

+--------------+---------+-----------+ 
| primary key? | tag ids | image ids | 
+--------------+---------+-----------+ 

स्पष्टीकरण

विल किसी तालिका में प्राथमिक कुंजी डेटाबेस को तोड़ने नहीं होने?

+0

प्राथमिक कुंजी _required_ है? नहीं। क्या लगभग हमेशा एक उम्मीदवार होता है? हाँ। आप किसी भी इंडेक्स के साथ एक टेबल का उपयोग कर सकते हैं, लेकिन यह गति के लिए एक महान दृष्टिकोण नहीं है। :-) – Wiseguy

उत्तर

6

लिंक तालिका में प्राथमिक कुंजी की आवश्यकता नहीं है। हालांकि एक यौगिक कुंजी एक अच्छा विचार है। UNIQUE (tag_ids, image_ids)

+1

एक 'अद्वितीय' कुंजी अनिवार्य रूप से इस स्थिति में 'प्राथमिक' कुंजी के समान ही है। http://stackoverflow.com/questions/158392/primary-key-versus-unique-constraint – ceejayoz

+0

@ceejayoz - बिंदु यह है कि आप एक जटिल तालिका में कई अद्वितीय बाधाओं को प्राप्त कर सकते हैं। और वह प्राथमिक कुंजी अनिवार्य नहीं है। लेकिन हां अद्वितीय इस मामले में प्राथमिक कुंजी के समान व्यवहार करेगा। –

5

हां, आपकी प्राथमिक कुंजी tag_id और image_id की यौगिक/समग्र कुंजी होनी चाहिए, यानी PRIMARY KEY (tag_id, image_id)। इस मामले में अतिरिक्त ऑटोइनक्रिकमेंट कॉलम की आवश्यकता नहीं है।

+0

कंपाउंड/समग्र मेरे लिए एक नया शब्द है। क्या यह कहना है कि अगर 'tag_id = 23' और 'image_id = 54', तो' linke_id' (प्राथमिक कुंजी) 2354 होना चाहिए? प्राथमिक कुंजी कॉलम रखने का क्या फायदा है? –

+0

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

+0

धन्यवाद, यह बहुत उपयोगी है। –

8

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

हालांकि, कोई आवश्यकता नहीं है कि प्राथमिक कुंजी केवल एक फ़ील्ड हो। इस मामले में आप अपनी प्राथमिक कुंजी (tag_id, image_id) घोषित कर सकते हैं।

आपको एक और पोस्ट के जवाब में एक प्रश्न है जो मुझे यह विचार देता है कि शायद आप सोच रहे हैं कि आपको प्राथमिक कुंजी बनाने के लिए दो क्षेत्रों को जोड़ना चाहिए। मत करो। के रूप में

alter table link add primary key (tag_id, image_id); 

कुंजी मत कहो

alter table link add primary key (tag_id + image_id); 

(मुझे लगता है कि परिभाषित करें "+" MySQL में संयोजन ऑपरेटर है। यह एक समय हो गया है। एसक्यूएल मानक है "&" लेकिन MySQL कि का उपयोग करता है कुछ और के लिए।)

वहाँ दोनों के बीच एक बड़ा अंतर है, अर्थात्, पहले मामले में, 25,34 और 253,4 दो अलग-अलग मान है, जबकि दूसरे मामले में वे दोनों 2534.

में बदल गया हो रहे हैं

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

create index link_tag_image on link(tag_id, image_id); 
create index link_image_tag on link(image_id, tag_id); 

आप केवल पहले (उदाहरण के लिए), तो विचार करें कि इस प्रश्न करते हैं:

select tag.name 
from image 
join link on image.image_id=link.imagae_id 
join tag on tag.tag_id=link.tag_id 
where image.foo='bar' 

यह plausbile पर्याप्त लगता है: लगता है कि सभी टैग छवियों कि एक निश्चित शर्त को पूरा मेल खाते हैं। लेकिन दूसरी अनुक्रमणिका के बिना, इस क्वेरी में बहुत लंबा समय लग सकता है, क्योंकि डीबी को दिए गए image_id के साथ सभी रिकॉर्ड्स खोजने के लिए अनुक्रमिक रूप से संपूर्ण लिंक तालिका को पढ़ना होगा।

0

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