मुझे लगता है कि जरूरत एक बहुत मजबूत शब्द है, और एक सख्त अर्थ में, तालिकाओं को शायद सरोगेट कुंजी की आवश्यकता नहीं है ।
हालाँकि, अगर यह मेरा डेटाबेस होता, तो मैं शायद सरोगेट कीज को भी जोड़ देता। मैं जरूरी नहीं चाहता कि मेरा डेटाबेस डिजाइन तीसरे पक्ष (IATA, ISO) के एक समूह पर निर्भर हो, चाहे उनका मानक कितना भी स्थिर क्यों न हो। या, मैं किसी विशेष मानक पर बिल्कुल भी निर्भर नहीं रहना चाहूंगा (क्या अन्य मुद्रा कोड मानक हैं? मुझे नहीं पता)। मैं शायद सरोगेट कुंजियों के साथ अपनी टेबल को मॉडल करूँगा जैसे:
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_id int (PK)| |country_id int (PK) |
|iata_airport_code string | |iso_country_code string |
|icao_airport_code string | +------------------------+
|faa_identifier string |
|address string |
|name string |
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_id int (PK) |
|iso_currency_code string |
|name string |
+-------------------------+
दूसरे शब्दों में, जब तक कि उन उद्योग मानक कोड मेरे आवेदन के लिए महत्वपूर्ण नहीं हैं, मैं उन्हें अपनी तालिकाओं के पीके के रूप में उपयोग नहीं करूंगा। वे सिर्फ लेबल हैं। मेरी अधिकांश अन्य सारणियों में संभवतः वैसे भी सरोगेट कुंजियाँ होंगी, और यह सेटअप मेरे डेटा मॉडल में निरंतरता जोड़ देगा। सरोगेट कुंजी को 'जोड़ने' की लागत न्यूनतम है।
कुछ टिप्पणियों के आधार पर अपडेट करें:
उदाहरण तालिकाओं के संदर्भ को जानने के बिना, यह जानना असंभव है कि डेटाबेस का उपयोग करके IATA हवाई अड्डा कोड जैसी महत्वपूर्ण चीजें आवेदन के लिए कितनी महत्वपूर्ण हैं। जाहिर है, अगर IATA कोड संपूर्ण अनुप्रयोग में व्यापक रूप से महत्वपूर्ण और उपयोग किए जाते हैं, तो यह सही विश्लेषण के बाद, तालिका के PK के रूप में कोड का उपयोग करने के लिए सही निर्णय हो सकता है।
हालाँकि, यदि तालिका सिर्फ एक लुकअप तालिका है जिसका उपयोग ऐप के कुछ कोनों में किया जाता है, तो IATA कोड्स का सापेक्ष महत्व डेटाबेस इन्फ्रास्ट्रक्चर में इस तरह के प्रमुख स्थान को सही नहीं ठहरा सकता है। निश्चित रूप से, आपको यहाँ और वहाँ कुछ प्रश्नों में एक अतिरिक्त शामिल होना पड़ सकता है, लेकिन यह प्रयास उस प्रयास की तुलना में तुच्छ हो सकता है, जिसमें यह सुनिश्चित करने के लिए शोध करना होगा कि आप आईएटीए कोड बनाने के निहितार्थ को पूरी तरह से समझते हैं। प्राथमिक कुंजी फ़ील्ड। कुछ मामलों में, न केवल मुझे परवाह नहीं है, लेकिन मैं आईएटीए कोड के बारे में परवाह नहीं करना चाहता हूं । @ जेम्स स्नेल की टिप्पणी नीचे एक सटीक उदाहरण है, जिसे मैं अपनी तालिका के पीके को प्रभावित करने के बारे में चिंता नहीं करना चाहता हूं।
इसके अलावा, डिजाइन में स्थिरता महत्वपूर्ण है। यदि आपके पास दर्जनों तालिकाओं के साथ एक डेटाबेस है जो सभी ने लगातार सरोगेट कुंजियों को डिज़ाइन किया है, और फिर कुछ लुकअप टेबल जो कि पीके के रूप में 3 पार्टी कोड का उपयोग कर रहे हैं, जो एक असंगति का परिचय देता है। यह पूरी तरह से खराब नहीं है, लेकिन इसके लिए प्रलेखन में अतिरिक्त ध्यान देने की आवश्यकता है और ऐसा नहीं किया जा सकता है। वे अच्छाई के लिए टेबल खोज रहे हैं , बस स्थिरता के लिए एक सरोगेट कुंजी का उपयोग करना पूरी तरह से ठीक है।
आगे के शोध पर आधारित अपडेट:
ठीक है, मुझे उत्सुकता हुई और मैंने सवाल के लिए लिंक के साथ शुरुआत करते हुए, मनोरंजन के लिए IATA एयरपोर्ट कोड पर कुछ शोध करने का फैसला किया।
जैसा कि यह पता चला है, आईएटीए कोड सार्वभौमिक और आधिकारिक नहीं हैं क्योंकि सवाल उन्हें बाहर करता है। इस पृष्ठ के अनुसार :
अधिकांश देश अपने आधिकारिक वैमानिकी प्रकाशनों में चार-चरित्र वाले ICAO कोड का उपयोग करते हैं , IATA कोडों का नहीं।
इसके अलावा, आईएटीए कोड और आईसीएओ कोड एफएए पहचानकर्ता कोड से अलग हैं , जो अभी तक एयरफील्ड की पहचान करने का एक और तरीका है।
इन्हें लाने में मेरी बात यह नहीं है कि इस बारे में एक बहस शुरू की जाए कि कौन से कोड बेहतर या अधिक सार्वभौमिक या अधिक आधिकारिक या अधिक व्यापक हैं, लेकिन वास्तव में यह दिखाने के लिए कि एक मनमाने ढंग से तीसरे पक्ष के पहचानकर्ता के चारों ओर अपने डेटाबेस संरचना को डिजाइन करना कुछ ऐसा नहीं है जो मैं करना चाहता हूं। , जब तक ऐसा करने के लिए एक विशिष्ट व्यावसायिक कारण नहीं थे ।
इस मामले में, मुझे लगता है कि प्राथमिक डेटाबेस के उम्मीदवार के रूप में IATA कोड (या किसी भी 3 पार्टी, संभावित परिवर्तनशील कोड) को छोड़कर, मेरा डेटाबेस बेहतर संरचित, अधिक स्थिर और अधिक लचीला होगा। ऐसा करने से, मैं किसी भी संभावित नुकसान से गुजर सकता हूं जो प्राथमिक कुंजी चयन के कारण फसल कर सकता है।