समग्र प्राथमिक कुंजी बनाम अतिरिक्त आईडी कॉलम?

कहें कि {Author, Title, Edition} विशिष्ट रूप से किसी पुस्तक की पहचान करता है, तो निम्नलिखित धारण करता है:

1. यह एक सुपरकी है -- विशिष्ट रूप से एक टपल (पंक्ति) की पहचान करती है।

2. यह इरेड्यूसबल है -- किसी भी कॉलम को हटाने से यह अब कुंजी नहीं बन जाता है।

3. यह एक उम्मीदवार कुंजी है -- एक इरेड्यूसबल सुपरकी एक उम्मीदवार कुंजी है।

अब आइए आईडी (पूर्णांक) पर विचार करें

मैं तर्क कर सकता हूं कि Book तालिका कुंजी कुछ अन्य तालिकाओं में एक विदेशी कुंजी के रूप में और कुछ अनुक्रमणिका में भी दिखाई देगी। तो, यह काफी जगह लेगा - तीन कॉलम x 40 वर्ण (या जो कुछ भी ...) कहें - इनमें से प्रत्येक तालिका में और मिलान करने वाले इंडेक्स में।

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

alter table Book add BookID integer not null identity;

BookID . के साथ होने के नाते (होना चाहिए) अद्वितीय भी, Book तालिका में अब दो उम्मीदवार कुंजी हैं।

अब मैं BookID का चयन कर सकता हूं प्राथमिक कुंजी के रूप में।

alter table Book add constraint pk_Book primary key (BookID);

हालांकि, {Author,Title,Edition} होना चाहिए रोकने . के लिए एक कुंजी (अद्वितीय) बने रहें कुछ इस तरह:

BookID  Author      Title           Edition
-----------------------------------------------
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

इसे सारांशित करने के लिए, BookID . जोड़ना -- और इसे प्राथमिक के रूप में चुनना -- बंद नहीं हुआ {Author, Title, Edition} एक (उम्मीदवार) कुंजी होने के नाते। इसकी अभी भी अपनी अनूठी बाधा और आमतौर पर मेल खाने वाली अनुक्रमणिका होनी चाहिए।

यह भी ध्यान दें कि डिजाइन बिंदु से, यह निर्णय "भौतिक स्तर" पर किया गया था। सामान्य तौर पर, डिज़ाइन के तार्किक स्तर पर, यह ID मौजूद नहीं है - इसे कॉलम आकार और अनुक्रमणिका के विचार के दौरान पेश किया गया था। तो, भौतिक स्कीमा तार्किक से ली गई थी। DB आकार, RDBMS और उपयोग किए गए हार्डवेयर के आधार पर, उस आकार-तर्क में से किसी का भी मापन योग्य प्रभाव नहीं हो सकता है -- इसलिए {Author, Title, Edition} का उपयोग करना एक PK के रूप में पूरी तरह से अच्छा डिज़ाइन हो सकता है -- जब तक कि अलग तरह से सिद्ध न हो जाए।