क्या प्रत्येक और प्रत्येक टेबल में एक प्राथमिक कुंजी होनी चाहिए?

340

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

क्या प्रत्येक और प्रत्येक टेबल में एक प्राथमिक कुंजी होनी चाहिए?

database  database-design 
— डैनियल सिल्वेरा
स्रोत
5
क्या आप तालिका के बारे में कुछ और जानकारी दे सकते हैं? जवाब शायद "हाँ" है।
— रयान बैर
7
हां, प्रत्येक तालिका में प्राथमिक कुंजी होनी चाहिए।
— सैयद तय्यब अली

जवाबों:

313

संक्षिप्त उत्तर: हाँ ।

लंबा जवाब:

  • आपको किसी चीज़ पर शामिल होने के लिए अपनी तालिका की आवश्यकता है
  • यदि आप चाहते हैं कि आपकी तालिका को व्यवस्थित किया जाए, तो आपको किसी प्रकार की प्राथमिक कुंजी की आवश्यकता होती है।
  • यदि आपकी टेबल डिज़ाइन को एक प्राथमिक कुंजी की आवश्यकता नहीं है, तो अपने डिज़ाइन को फिर से पढ़ें: सबसे शायद, आप कुछ याद कर रहे हैं। समान रिकॉर्ड क्यों रखते हैं?

MySQL में, InnoDB स्टोरेज इंजन हमेशा एक प्राथमिक कुंजी बनाता है यदि आपने इसे स्पष्ट रूप से निर्दिष्ट नहीं किया है, तो इस प्रकार एक अतिरिक्त कॉलम बनाते हैं जिसे आप एक्सेस नहीं करते हैं।

ध्यान दें कि एक प्राथमिक कुंजी समग्र हो सकती है।

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

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

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

इस लेख को मेरे ब्लॉग में देखें कि आपको हमेशा अद्वितीय डेटा पर एक अद्वितीय सूचकांक क्यों बनाना चाहिए:

PS कुछ बहुत, बहुत विशेष मामले हैं जहां आपको प्राथमिक कुंजी की आवश्यकता नहीं है।

अधिकतर वे लॉग टेबल शामिल करते हैं जिनमें प्रदर्शन कारणों से कोई अनुक्रमणिका नहीं होती है।

— Quassnoi
स्रोत
उनके पास अभी भी एक प्राथमिक कुंजी है, समग्र एक
— क्रिस्तोफ
2
@annakata: उनके पास एक समग्र प्राथमिक कुंजी होनी चाहिए
— क्वासोई
1
"और चूंकि किसी भी प्राथमिक कुंजी में UNIQUE सूचकांक बनाना शामिल है" Oracle के लिए सही नहीं है। एक प्राथमिक कुंजी लागू करने के लिए एक गैर-अद्वितीय सूचकांक का उपयोग कर सकता है। वास्तव में, यह कभी-कभी आवश्यक है कि अद्वितीय और पीके बाधाएं गैर-अद्वितीय अनुक्रमित का उपयोग करें।
— स्टेफनी पेज
3
सिर्फ बयान पर एक टिप्पणी "क्यों समान रिकॉर्ड रखें?"। ध्यान दें कि सिर्फ PK जोड़ने से यह सुनिश्चित नहीं होगा कि कोई दोहराव नहीं है। अक्सर पीके उपयोगकर्ता को दिखाई नहीं देता है, इसलिए जो महत्वपूर्ण है वह दृश्य क्षेत्रों में है, जिसमें डुप्लिकेट डेटा हो सकता है। आपके डिजाइन के आधार पर यह वांछनीय हो सकता है या नहीं।
— रोसको
1
कुंजियों का जुड़ाव से कोई लेना-देना नहीं है। और क्लस्टरिंग तर्क इस बात पर निर्भर करता है कि आप किस डीबीएमएस का उपयोग करते हैं, और तार्किक और भौतिक विचारों को मिलाते हैं।
— जॉन हेग्लैंड
36

हमेशा प्राथमिक कुंजी रखने के लिए सबसे अच्छा है। इस तरह यह पहले सामान्य रूप से मिलता है और आपको डेटाबेस सामान्यीकरण पथ पर जारी रखने की अनुमति देता है।

जैसा कि दूसरों द्वारा कहा गया है, प्राथमिक कुंजी नहीं होने के कुछ कारण हैं, लेकिन प्राथमिक कुंजी होने पर अधिकांश को नुकसान नहीं होगा

— माइकल व्हीलर
स्रोत
5
@PaSSart डेटा को हमेशा अपने सामान्य रूपों में नहीं होना चाहिए। वास्तव में, जब डेटा विशाल हो जाता है, तो इसे अपने सामान्य रूप में नहीं रखा जाना चाहिए अन्यथा डेटा एक्सेस करना टेबल जॉइन करने वाले प्रश्नों आदि के लिए भयानक रूप से धीमा होगा। सामान्य रूप एक "आदर्शीकरण" है और व्यावहारिक रूप से केवल तभी संभव है जब डेटा बढ़ने की उम्मीद न हो। विशाल।
— पचेरियर
13

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

— tvanfosson
स्रोत
13
ज्वाइन टेबल एक प्राथमिक कुंजी है - एक संयुक्त एक, जिसमें पीके के दोनों रिकॉर्ड शामिल हैं। जैसे क्रिएट टेबल पर्सोएडर (पर्सोएड इंट, ऑर्डरआईडी इंट, प्रायररी कुंजी (पर्सिआइड, ऑर्डरआईड))।
— कीथ विलियम्स
3
हां, लेकिन क्या होगा अगर लिंक टेबल में एक तीसरी विशेषता भी है, तो "ऑर्डरडेट" कहें। क्या आप इसे समग्र कुंजी में भी जोड़ देंगे? IMHO नहीं - क्योंकि यह आगे reducable है और नहीं-reducable characterstic एक प्राथमिक कुंजी होना चाहिए की सेवा नहीं करता है।
— स्टेपवेक
13

कुछ बहुत ही दुर्लभ मामलों (संभवतः कई-से-कई संबंध तालिका, या आपके द्वारा अस्थायी रूप से बड़ी मात्रा में डेटा लोड करने के लिए उपयोग की जाने वाली तालिका) को छोड़कर, मैं कह रहा हूं:

यदि इसके पास प्राथमिक कुंजी नहीं है, तो यह तालिका नहीं है!

न घुलनेवाली तलछट

— marc_s
स्रोत
10
कड़ाई से कहना कि वाक्य गलत है। टेबल्स आपकी क्वेरी भाषा द्वारा बनाई गई "व्यू टेबल्स" हो सकती हैं। एक RDBMS संबंधों में शामिल है तालिकाओं में नहीं। उस वाक्य को कहना चाहिए: "अगर इसमें प्राथमिक कुंजी नहीं है, तो यह एक संबंध नहीं है!"।
— चरण
या शायद, "अगर कोई उम्मीदवार कुंजी नहीं है तो यह एक संबंधपरक तालिका नहीं है"। लेकिन बहुत ही दुर्लभ मामलों को देखें जहां एक तालिका होना ठीक है जो एक संबंध का प्रतिनिधित्व नहीं करता है।
— वाल्टर मिती
कई-से-कई तालिका में प्राथमिक कुंजी क्यों नहीं होगी? आप एक अलग प्राथमिक कुंजी बना सकते हैं और फिर विदेशी कुंजियों की सरोगेट के लिए एक अद्वितीय सूचकांक बना सकते हैं। मुझे लगता है कि हर मेज पर एक प्राथमिक कुंजी रखना बेहतर है। यहां तक ​​कि बल्क लोडिंग टेबल पर आप एक प्राथमिक कुंजी को अलग से पहचानना चाह सकते हैं जो आयात किए जा रहे डेटा के समावेशी नहीं है क्योंकि यह आपको ईटीएल प्रक्रिया में डुप्लिकेट रिकॉर्ड की पहचान करने में मदद कर सकता है। यह मुझे लगता है कि प्रत्येक तालिका में अभी भी एक प्राथमिक कुंजी होनी चाहिए, भले ही यह थोड़ा अधिक भंडारण हो। एक दृश्य द्वारा बनाई गई तालिका एक तालिका का एक सबसेट है न कि एक तालिका।
— जॉन अर्नेस्ट
1
कई से कई रिलेशनशिप टेबल में, आप एक समग्र प्राथमिक कुंजी बना सकते हैं, जिसमें दोनों आईडी से रिश्ते शामिल हों।
— जाप
8

बस इसे जोड़ें, आपको बाद में खेद होगा जब आपने नहीं किया था (चयन करना, हटाना, लिंक करना, आदि)

— raphaëλ
स्रोत
8

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

आप कहते हैं कि आपके पास कोई प्राकृतिक कुंजी नहीं है, इसलिए आपके पास अद्वितीय बनाने के लिए फ़ील्ड का कोई संयोजन नहीं है, इससे आर्टफ़िशियल कुंजी महत्वपूर्ण हो जाती है।

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

— HLGEM
स्रोत
6

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

पुस्तकें ऑनलाइन (SQL सर्वर के लिए) प्राथमिक कुंजी और संकुल अनुक्रमित अनुभाग देखें

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

लेकिन फिर इसे भी देखें: http://www.aisintl.com/case/primary_and_foreign_key.html

— endo64
स्रोत
1
— endo64
4
वह पेज काफी बेवकूफ है। सबसे पहले, प्रदर्शन कारणों से एक प्राथमिक कुंजी की आवश्यकता होती है। उनके पेज को पढ़कर मुझे पता चला कि एक बुक टेबल पर एक आईडी जोड़ना बेकार है क्योंकि पुस्तक का पाठ अद्वितीय है; जाहिर है, आदमी ने कभी डेटाबेस के साथ काम नहीं किया। लेकिन उसे यह समझने में भी समस्या है कि वह क्या आलोचना करता है। पृष्ठ में लिखा है कि 1) एक PK मान पंक्ति 2 का संदर्भ देता है) आप स्तंभों के किसी भी सेट से 2 तालिकाओं को जोड़ सकते हैं। कोई विरोधाभास नहीं है। यह आश्चर्यजनक है कि एक अकादमिक लेख लेखक संबंधपरक सिद्धांत के मूल को नहीं समझता है।
— फेडेरिको रेज़ोली
1
"पहले, प्रदर्शन कारणों से एक प्राथमिक कुंजी की आवश्यकता है" यह गलत है, पीके प्रदर्शन पर प्रत्यक्ष प्रभाव नहीं डालता है। पीके नहीं होने से कई समस्याएं हो सकती हैं (एक पंक्ति की पहचान करना, शामिल होना आदि), लेकिन प्रदर्शन उनमें से एक नहीं है। जब आप तालिका पर पीके बनाते हैं SQL सर्वर एक अद्वितीय-क्लस्टर इंडेक्स बनाता है, तो वह इंडेक्स प्रदर्शन को प्रभावित करता है न कि पीके ही। एक वास्तविक उदाहरण के रूप में, मेरी तालिका में दिनांक स्तंभ पर एक गुच्छित सूचकांक और GUID फ़ील्ड पर PK है, क्योंकि मेरी पंक्तियों को तालिका में दिनांक स्तंभ पर भौतिक रूप से आदेश दिया जाना चाहिए क्योंकि सभी प्रश्नों की तिथि सीमा (मेरे मामले में) है।
— एंडियो 64
यह क्लस्टर इंडेक्स SQL ​​सर्वर और कई अन्य DBMS द्वारा बनाए गए प्राथमिक कुंजी का एक स्वाद है। क्या आप सुनिश्चित हैं कि इसका उपयोग करना एक अच्छा विचार है? उदाहरण के लिए, MySQL में, यह कई अवांछित कारणों से नहीं है।
— फेडेरिको रेज़ोली
1
ध्यान रखें कि GUID PKs के लिए, InnoDB में एक इष्टतम प्रकार नहीं है। सभी अनुक्रमितों में PK का संदर्भ होता है, इसलिए जितना बड़ा PK होता है, उतना ही बड़ा अन्य सभी अनुक्रमित होगा।
— फेडेरिको रेज़ोली
6

सुझाए गए उत्तर से असहमत हैं। संक्षिप्त उत्तर है: सं ।

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

हालांकि ऐसे मामले हैं, उदाहरण के लिए समय-श्रृंखला डेटा लॉगिंग, जहां एक ऐसी कुंजी का अस्तित्व बस जरूरत नहीं है और बस मेमोरी लेता है। एक पंक्ति को अद्वितीय बनाना बस ... आवश्यक नहीं है!

एक छोटा उदाहरण: टेबल ए: लॉगडाटा

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

कोई प्राथमिक कुंजी की आवश्यकता नहीं है।

तालिका B: उपयोगकर्ता

Columns: Id, FirstName, LastName etc.

LogData तालिका के लिए "विदेशी कुंजी" के रूप में उपयोग करने के लिए प्राथमिक कुंजी (Id) की आवश्यकता होती है।

— थियोडोर ज़ियोग्रॉस
स्रोत
3

मुझे पता है कि .NET में ग्रिडव्यू की कुछ विशेषताओं का उपयोग करने के लिए, आपको ग्रिडव्यू के लिए प्राथमिक कुंजी की आवश्यकता है ताकि पता चल सके कि किस पंक्ति को अपडेट करने / हटाने की आवश्यकता है। सामान्य अभ्यास में प्राथमिक कुंजी या प्राथमिक कुंजी क्लस्टर होना चाहिए। मैं व्यक्तिगत रूप से पूर्व को पसंद करता हूं।

— Tacoman667
स्रोत
3

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

— StewNoble
स्रोत
मुझे यकीन नहीं है कि यह अभी तक आवश्यक है, लेकिन "इसे करें क्योंकि अन्यथा किसी को बाद में परिणामों से निपटना होगा" मुझे इसे करने के पक्ष में गलत करने के लिए पर्याप्त है। मैं हमेशा कॉलम को बाद में छोड़ सकता हूं अगर यह इसे नीचे सिकोड़ने के लिए सार्थक लगता है ...
— ArtOfWarfare
3

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

— शिव
स्रोत
2

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

— rvarcher
स्रोत
1

संक्षेप में, नहीं। हालाँकि, आपको यह ध्यान रखने की ज़रूरत है कि कुछ क्लाइंट एक्सेस CRUD ऑपरेशंस की आवश्यकता है। भविष्य के प्रमाण के लिए, मैं हमेशा प्राथमिक कुंजियों का उपयोग करता हूं।

— Rich.Carpenter
स्रोत
1

यदि आप हाइबरनेट का उपयोग कर रहे हैं तो प्राथमिक कुंजी के बिना इकाई बनाना संभव नहीं है। यदि आप एक मौजूदा डेटाबेस के साथ काम कर रहे हैं जो सादे sql / ddl स्क्रिप्ट के साथ बनाया गया था, और यह कोई प्राथमिक कुंजी नहीं थी, तो यह समस्याएँ पैदा कर सकती हैं

— Schildmeijer
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.