क्या इन विशिष्ट तालिकाओं को सरोगेट कुंजी की आवश्यकता है?


13

पृष्ठभूमि

मेरे पास यह टेबल हैं

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

AIRPORT_CODE है आईएटीए (इंटरनेशनल एयर ट्रांसपोर्ट एसोसिएशन) हवाई अड्डे का कोड , आप उन्हें अपने सामान टैग में देख सकते हैं जब आप हवाई जहाज से यात्रा करते हैं।

यहाँ छवि विवरण दर्ज करें

COUNTRY_CODE है आईएसओ 3166-1 ए 3 मानक देश कोड , तो आप उन्हें ओलंपिक में देख सकते हैं।

यहाँ छवि विवरण दर्ज करें

currency_code है IS0 417 मानक 3 वर्ण मुद्रा कोड , तो आप उन्हें अंतरराष्ट्रीय मुद्रा विनिमय प्रदर्शन बोर्डों में देख सकते हैं।

यहाँ छवि विवरण दर्ज करें

प्रशन

क्या ये प्राकृतिक पीके काफी अच्छे हैं?

विश्व सम्मानित मानकों का उपयोग कर रहा है, जो पीके के लिए पर्याप्त रूप से पूरे उद्योगों द्वारा स्वीकार किए जाते हैं?

क्या इस तालिकाओं को सरोगेट की जरूरत है, इससे कोई फर्क नहीं पड़ता?

जवाबों:


15

नहीं, वे नहीं। वे चाबियाँ निश्चित रूप से काफी अच्छी हैं!

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

PKs के अपरिवर्तनीय और संख्यात्मक-पूर्णांक के बारे में प्रतिबंध संबंधपरक मॉडल (Codd) या किसी SQL मानक (ANSI या अन्य) का हिस्सा नहीं हैं।


3
प्राथमिक कुंजी भी अपरिवर्तनीय होनी चाहिए, कुछ IATA हवाई अड्डे कोड निश्चित रूप से नहीं हैं। उन्हें IATA के चक्कर में बदला जा सकता है।
जेम्स स्नेल

3
@JamesSnell - IATA हवाई अड्डा कोड देश के कोड के रूप में अपरिवर्तनीय हैं। आप हर दशक में एक बार बदलाव की बात कर रहे हैं , यदि ऐसा है। मामले की चर्चा के लिए यहां देखें । बहुत सारे पुराने कोड हैं जो अभी भी जगह में हैं क्योंकि वे बदलने के लिए बहुत अधिक परेशानी वाले हैं। इसके अतिरिक्त, यह है कि एक CASCADE अपडेट किस लिए है। महान प्राथमिक कुंजी वैध हैं, यदि महान अभ्यास नहीं है।
बोबोंस

2
@ EricKing ये 3 पार्टी, कई उद्योगों के सभी प्रमुख दलों के प्रतिनिधियों से बनी होती है, फिर मानकों पर वर्षों तक चर्चा की जाती है, तब तक मतदान किया जाता है जब तक कि एक उचित सहमति नहीं बन जाती है। इसके अलावा वे उन तंत्रों पर सहमत होते हैं जिनके माध्यम से कोई परिवर्तन या नया परिवर्धन किया जाता है। इसके अलावा, कोड सूचियां मानकों को बनाया जाता है, न कि एक सनक पर, बल्कि इसलिए कि किसी चीज के लिए एक नियंत्रित, सम्मानित, सहमत सहमति, किसी चीज के लिए कोड की सूची बनाने की जरूरत होती है, ताकि दुनिया भर में आपस में संवाद स्थापित किया जा सके।
ट्यूलेंस कोर्डोवा

2
@ user61852 - आप कह सकते हैं इन मानकों रहे हैं बनाया प्राथमिक कुंजी हो सकता है।
बोबसन

3
@ बोबसन: "बहुत सारे पुराने कोड हैं जो अभी भी जगह में हैं क्योंकि उन्हें बदलने के लिए बहुत अधिक परेशानी है" -> संभवतः क्योंकि वे प्राथमिक कुंजी हैं?
मैकिज

2

मुझे लगता है कि जरूरत एक बहुत मजबूत शब्द है, और एक सख्त अर्थ में, तालिकाओं को शायद सरोगेट कुंजी की आवश्यकता नहीं है

हालाँकि, अगर यह मेरा डेटाबेस होता, तो मैं शायद सरोगेट कीज को भी जोड़ देता। मैं जरूरी नहीं चाहता कि मेरा डेटाबेस डिजाइन तीसरे पक्ष (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 पार्टी, संभावित परिवर्तनशील कोड) को छोड़कर, मेरा डेटाबेस बेहतर संरचित, अधिक स्थिर और अधिक लचीला होगा। ऐसा करने से, मैं किसी भी संभावित नुकसान से गुजर सकता हूं जो प्राथमिक कुंजी चयन के कारण फसल कर सकता है।


1
इसलिए IATA मानक एयरलाइनों के लिए पर्याप्त हैं, लेकिन आपके लिए नहीं?
ट्यूलेंस कोरडोवा

1
जब आप लंदन हीथ्रो से सामान की तलाश करना चाहते हैं, तो निश्चित रूप से आपको हवाई अड्डे की मेज तक सभी तरह से शामिल होना पड़ेगा, क्योंकि आप ऐसा नहीं कर सकते हैं select * from baggage where airport_code = 'LHR', जिसका अर्थ है कि डेटाबेस केवल अनुप्रयोग को फेंकने योग्य है, जो एक बहुत ही संकीर्ण और मालिकाना है दृष्टिकोण, विशेष रूप से जब व्यवसाय स्वामी वह है जो डेटाबेस के लिए भुगतान करता है, और इसलिए इसका मालिक है। इसके अलावा, आपको पीके कॉलिंस से बचने के लिए एक डेटाबेस से दूसरे डेटाबेस में डेटा आयात करने जैसी सांसारिक चीजें करने के लिए कोड लिखना होगा।
ट्यूलेंस कोर्डोवा

1
IATA कोड अपरिवर्तनीय नहीं हैं इसलिए उन्हें PK उम्मीदवार नहीं माना जा सकता है। उदाहरण: कोड IDL न्यूयॉर्क में था, जब तक इसका नाम बदलकर JFK नहीं कर दिया गया। IDL कोड अब मिसिसिपी में है।
जेम्स स्नेल

2
@ EricKing IATA और ISO देखभाल के बारे में कोड स्थिर, अद्वितीय और सार्वभौमिक स्वीकार किए जाते हैं। यह एक टेबल डिजाइन करने वाले व्यक्ति के हित के साथ बहुत मेल खाता है।
ट्यूलेंस कोर्डोवा

2
@ user61852 - सिर्फ इसलिए कि ये मानक कोड हैं इसका मतलब यह नहीं है कि एयरलाइन प्रणाली उन्हें पीके के रूप में उपयोग करती है (शायद आपके पास यहां अधिक जानकारी है?)। इतने बड़े पैमाने पर कैस्केडिंग अपडेट होने से यह बहुत बुरा विचार लगता है।
JeffO

1

जबकि खेतों पर सरोगेट चाबियां होना ठीक है और इसमें कुछ भी गलत नहीं है, इस पर विचार करने के लिए इंडेक्स पेज का आकार कुछ हो सकता है।

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

BIGINT, INT, SMALLINT, TINYINT या जो भी पूर्णांक जैसा डेटा प्रकार हो, आपको सड़क के नीचे कुछ परेशानी से बचा सकता है।

बस मेरे 2 सेंट

अपडेट करें:

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

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

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

यदि VARCHAR का उपयोग किया जाता है, जिसका अर्थ है कि रिक्ति एक समान नहीं है, जब तक कि डेटा हमेशा समान नहीं होता (जिस बिंदु पर एक CHAR मान अधिक प्रभावी होता है)। यह सूचकांक को धीमा बनाता है, और सर्वर पहले से ही हज़ारों और हज़ारों प्रश्नों को प्रति सेकंड में व्यस्त रखने के साथ अब इसे एक गैर-समान अनुक्रमणिका के गर्त में जाने में समय बर्बाद करना पड़ता है, और फिर से जुड़ने पर वही काम करें (जो इससे धीमा है अन-ऑप्टिमाइज़्ड टेबल पर नियमित चयन, DW को उदाहरण के रूप में लेते हैं जहाँ डेटा पुनर्प्राप्ति को गति देने के लिए कुछ संभव जोड़ होते हैं)। इसके अलावा अगर आप यूटीएफ का उपयोग करते हैं जो डेटाबेस इंजन के साथ भी गड़बड़ कर सकता है (मैंने कुछ मामले देखे हैं)।

व्यक्तिगत रूप से, मेरे स्वयं के अनुभव से, एक उचित रूप से संगठित सूचकांक में शामिल होने की गति ~ 70% तक बढ़ सकती है, और पूर्णांक कॉलम में शामिल होने से लगभग 25% (डेटा के आधार पर) के रूप में शामिल हो सकते हैं । जैसे-जैसे मुख्य टेबल बढ़ने लगती हैं और ये टेबल उन पर इस्तेमाल होने लगती हैं, क्या आपके पास एक पूर्णांक डेटाटाइप होगा जो स्तंभ पर कब्जा कर लेता है जिसमें कुछ बाइट्स होते हैं बनाम VARCHAR / CHAR फ़ील्ड होती है जो अधिक जगह घेरेगी। यह डिस्क स्पेस पर बचत, प्रदर्शन में वृद्धि और एक रिलेशनल डेटाबेस की समग्र संरचना के लिए नीचे आता है।

जेम्स स्नेल ने भी उल्लेख किया है:

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

इसलिए इसे ध्यान में रखते हुए, क्या आपको 1 रिकॉर्ड को अपडेट करना होगा, जो एक नंबर से जुड़ा होता है, बनाम यह अपडेट करने के लिए कि एक रिकॉर्ड प्लस उस तालिका के सभी रिकॉर्ड जिस पर आप शामिल होते हैं।


यह एक मान्य विचार है, लेकिन इन तालिकाओं की बात यह है कि प्रत्येक तालिका में केवल परिमित मात्रा में अभिलेख हैं। यदि आपके पास वास्तव में कोड आकार है small projectऔर bigger, कृपया स्पष्ट करने के लिए अपडेट करें कि यह क्यों मायने रखता है।
बोबसन

1
PKs के अपरिवर्तनीय और संख्यात्मक-पूर्णांक के बारे में प्रतिबंध संबंधपरक मॉडल (कोडेक) या किसी SQL मानक (ANSI या अन्य) का हिस्सा नहीं हैं।
ट्यूलेंस कोर्डोवा

4
निश्चित लंबाई के आधार पर सूचकांक , छोटे तार (जैसे आईएसओ कोड) पूर्णांक के रूप में तेज होते हैं। चर लंबाई, लंबे तार के आधार पर सूचकांक नहीं हैं।
ट्यूलेंस कोर्डोवा

यही कारण है कि मैंने कहा था (ऊपर VARCHAR बनाम CHAR भाग देखें) मुझे एक सांकेतिक पूर्णांक बनाम एक निश्चित लैंथ शॉर्ट स्ट्रिंग का परीक्षण करने का मौका नहीं मिला है, लेकिन मेरे पास ऐसा करने के लिए एक चर लैंथ और पूर्णांक
टोनी के

2
ज्वाइन परफॉर्मेंस एक स्ट्रॉ मैन है। अक्सर, प्राकृतिक कुंजियों का उपयोग करने का मतलब है कि आपको पहली जगह में शामिल होने की आवश्यकता नहीं है।
माइक शेरिल 'कैट रिकॉल'

1

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

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

कुछ ऐसे मामले हैं जो अमेरिका के लिए विशिष्ट हैं, जहां मानकों में भारी बदलाव किया गया था: पोस्टल कोड का विस्तार 5 से - 9 अंकों से किया गया, एक संक्षिप्त 2 अक्षरों के लिए राज्य के संक्षिप्त विवरण और अवधि से छुटकारा पाएं (याद रखें कि जब इलिनोइस बीमार था?), और अधिकांश दुनिया को Y2K से निपटने के लिए मिला। यदि आपके पास अरबों रिकॉर्ड वाले दुनिया भर में फैले डेटा के साथ एक वास्तविक समय वाला ऐप है, तो कैस्केडिंग अपडेट सबसे अच्छा विचार नहीं है, लेकिन क्या हमें उन सभी जगहों पर काम करना चाहिए जो इस तरह की चुनौतियों का सामना करते हैं? उस डेटासेट के साथ, आप अपने लिए इसका परीक्षण कर सकते हैं और अधिक विस्तृत उत्तर के साथ आ सकते हैं।


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

वैसे, "मैं हर समय सरोगेट कुंजी का उपयोग करता हूं" नियम रिलेशनल मॉडल (कॉड्स) में नहीं है और न ही अन्य एसक्यूएल मानक। ओरेकल डेटा डिक्शनरी योजना जब भी संभव हो और अन्य उदाहरणों में कृत्रिम कुंजी का उपयोग करती है। PPDM ( ppdm.org ) भी मिश्रित दृष्टिकोण की सिफारिश करता है और इसे अपने मॉडल में उपयोग करता है। ANSI SQL स्टैंडर्ड का कहना है कि ऑल सरोगेट्स के बारे में कुछ भी नहीं है। मुझे लगता है कि ऑल-सरोगेट्स और ऑल-नेचुरल संक्षारक हैं। कुछ प्राकृतिक और कुछ सरोगेट जो रिलेशनल मॉडल सिखाते हैं।
ट्यूलेंस कोर्डोवा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.