संबंधपरक डेटाबेस में लुकअप तालिकाओं के बारे में सबसे अच्छे अभ्यास क्या हैं?

Question

लुकअप टेबल (या कोड टेबल , जैसा कि कुछ लोग उन्हें कहते हैं) आमतौर पर उन संभावित मूल्यों का एक संग्रह है जो एक निश्चित कॉलम के लिए दिए जा सकते हैं।

उदाहरण के लिए, मान लें कि हमारे पास एक लुकअप टेबल है party(जिसका अर्थ राजनीतिक दलों के बारे में जानकारी संग्रहीत करना है) जिसमें दो कॉलम हैं:

• party_code_idn, जो सिस्टम-जनित संख्यात्मक मान रखता है, और ( व्यावसायिक डोमेन अर्थ की कमी ) वास्तविक कुंजी के लिए एक किराए के रूप में काम करता है।
• party_code, तालिका की वास्तविक या "प्राकृतिक" कुंजी है क्योंकि यह उन मानों को बनाए रखता है जिनमें व्यावसायिक डोमेन अर्थ हैं।

और हम कहते हैं कि ऐसी तालिका उस डेटा को बनाए रखती है जो निम्न प्रकार है:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

party_codeस्तंभ, जो मूल्यों 'रिपब्लिकन' और 'डेमोक्रेटिक', टेबल की असली कुंजी जा रहा है, एक अद्वितीय बाधा के साथ की स्थापना की है, लेकिन मैं वैकल्पिक रूप से जोड़ा रहता है party_code_idn, और यद्यपि तालिका (के पी के रूप में परिभाषित तार्किक बोल , party_codeप्राथमिक कुंजी [पीके]) के रूप में काम कर सकते हैं।

सवाल

लेन-देन तालिकाओं से मान देखने के लिए सर्वोत्तम अभ्यास क्या हैं ? क्या मुझे मूल्यों को सरोगेट करने के लिए फॉरवर्ड (FK) संदर्भ या तो (a) सीधे प्राकृतिक और सार्थक मूल्य या (b) में स्थापित करना चाहिए ?

विकल्प (ए) , उदाहरण के लिए,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

निम्नलिखित गुण हैं ¹ :

1. अंतिम उपयोगकर्ता (+) के लिए पठनीय
2. सिस्टम में आयात-निर्यात के लिए आसान (+)
3. मूल्य को बदलने में मुश्किल है क्योंकि इसमें सभी संदर्भ तालिकाओं में संशोधन की आवश्यकता है (-)
4. नया मूल्य जोड़ना महंगा नहीं है (=)

मुझे लगता है कि यह अनुप्रयोग प्रोग्रामिंग शब्दजाल में फ़ंक्शन कॉल से एक सादृश्य बनाने के लिए लगभग " मान से पास " जैसा है।

उदाहरण के लिए विकल्प (बी) ,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

नीचे गुण हैं:

1. अंतिम उपयोगकर्ता के लिए पठनीय नहीं (-)
2. आयात करने के लिए निर्यात करना मुश्किल है क्योंकि हमें इसे डी-रेफर करने की आवश्यकता है (-)
3. मूल्यों को बदलने में आसान, क्योंकि हम केवल लेनदेन तालिकाओं में संदर्भ संग्रहीत कर रहे हैं (+)
4. नया मूल्य जोड़ना महंगा नहीं है (=)

यह " संदर्भ द्वारा पास " के समान है , अगर ऐप प्रोग्रामिंग पार्लेंस में फ़ंक्शन कॉल की तुलना करता है ।

आयात-निर्यात भी एक अलग तरीके से किया जा सकता है, यानी, बस फिर से लुक-अप टेबल को पॉपुलेट करके और फिर सरोगेट कॉलम को फिर से बीजित करें। मुझे आशा है कि मुझे यह अधिकार मिल रहा है, यह एक ऐसी चीज है जिसे मैंने सिर्फ एक संभावना के रूप में सुना है।

_{1. ध्यान दें +, -और =उन गुणों के लाभ का संकेत दें ।}

सवाल

महत्वपूर्ण रूप से: अगर हम सिर्फ बाद वाले दृष्टिकोण का उपयोग करने जा रहे हैं तो क्या लुकअप (या कोड ) टेबल और एफके संदर्भ के बीच अंतर है ? मुझे लगता है कि वे सिर्फ एक ही काम करते हैं।

संबंधित संसाधन

• लुकअप टेबल्स कितने महत्वपूर्ण हैं?

• कोड या लुकअप टेबल्स के साथ सर्वश्रेष्ठ अभ्यास

• लुकअप टेबल्स बेस्ट प्रैक्टिस डीबी टेबल्स या एनुमरेशन्स

Answer 1

द्वारा IDN, मैं इसे आप एक IDENTITY, SEQUENCEया AUTO_INCREMENTक्षेत्र का मतलब ले ? आपको यहां और यहां देख लेना चाहिए ।

नोट, खंड 5 (डेटा तत्वों के रूप में डेटा मूल्यों का दुरुपयोग), आंकड़ा 10 के नीचे

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

तो, यह विशेषज्ञ सोचता है कि आपको सरोगेट कुंजियों को "टालना" चाहिए। यह वास्तव में काफी बुनियादी एसक्यूएल तकनीक है और इससे आपके दिन-प्रतिदिन एसक्यूएल में कोई समस्या नहीं होनी चाहिए। ऐसा प्रतीत होता है कि आंकड़ा 10 में एक त्रुटि है - Sales_person in SalesData को एक सरोगेट कुंजी (यानी एक संख्या) होनी चाहिए, पाठ नहीं। मैं ऊपर के उद्धरण से इसका उल्लेख कर रहा हूं।

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

ऊपर दिए गए दूसरे संदर्भ से:

सामान्यीकरण निरर्थक डेटा को समाप्त कर देता है, इस प्रकार डेटा अखंडता को सरल रूप से लागू करने का कार्य करता है, लेकिन MUCK बनाने की प्रक्रिया पूरी तरह से कुछ और है, लेकिन DNSCK अनावश्यक डेटा को समाप्त नहीं करता है, बल्कि वे इस बात का खात्मा करते हैं कि निरर्थक तालिकाएँ क्या हैं। जैसा कि मैं प्रदर्शित करूंगा, कम तालिकाओं में समान सादगी नहीं है।

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

Comments

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

— निशांत

"डेरेफेरिंग" स्ट्रेटेजम निश्चित रूप से बहुसंख्यक दृष्टिकोण प्रतीत होता है। थोड़ा प्रयोग क्यों न करें और देखें कि आप कैसे प्राप्त करते हैं? कुछ प्राकृतिक कुंजियों को चुनें और देखें कि आपकी एसक्यूएल कैसे काम करती है - फिर एक सरोगेट निर्दिष्ट करें और थोड़ी देर के लिए उसके साथ गड़बड़ करें। सेल्को और पास्कल का सम्मान एसक्यूएल / रिलेशनल दुनिया में किया जाएगा, लेकिन मैंने लोगों को यह कहते हुए बहस करते देखा है कि उनका दृष्टिकोण बहुत सिद्धांतवादी और शुद्धतावादी है - और "वास्तविक दुनिया" सिस्टम को सरोगेट कुंजी का उपयोग करना होगा। यदि आपकी प्राकृतिक कुंजी तीन फ़ील्ड्स की है और वह आगे किसी FOREIGN KEYअन्य तालिका में है, तो यह बहुत गड़बड़ हो सकती है लेकिन YMMV।

— वेर

हाँ tbh मैं इस purist सोच था और मैं क्यों ppl सरोगेट कुंजी का उपयोग कर रहा था! और फिर कुछ उपयोग मामलों को शुद्ध दुनिया में संभालना वास्तव में मुश्किल लग रहा था। मुझे लगा कि सरोगेट अप्रोच अधिक आसान है हालांकि आपको आयात और निर्यात के कुछ नुकसान हैं। वास्तव में संयोजन परिदृश्य पेचीदा हो सकता है। Btw कोड टेबल्स सरोगेट परिदृश्य में विदेशी कुंजी से बहुत अलग नहीं हैं? मेरा मतलब है कि तार्किक अंतर मौजूद है, लेकिन इसके अलावा एक विदेशी कुंजी नहीं है।

— निशांत

आप अपनी प्राकृतिक कुंजियों को UNIQUE CONSTRAINTएस और NOT NULLएस के माध्यम से लागू कर सकते हैं - ठीक है, आपकी कोड टेबल प्रविष्टियां FOREIGN KEYउन तालिकाओं में हैं जो उपयोग / उनका संदर्भ देती हैं - इसलिए अवधारणाएं संबंधित हैं, लेकिन समान नहीं हैं। कोड तालिका की सरोगेट कुंजी वह फ़ील्ड है जो "बच्चे" तालिका में दिखाई देती है - निश्चित रूप से कम सुपाठ्य है, लेकिन INTबहुत बड़ी नहीं है - बहुत अधिक स्थान की आवश्यकता नहीं है जो सरोगेट कुंजी का लाभ है।

— Vérace

Answer 2

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

Idn: 1
Name: Democrats
Code: D      (or DEM)

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

इस शैली को संक्षिप्त नाम एन्कोडिंग कहा गया है। मैं इस पर सेलको के लेखन की सिफारिश कर सकता हूं। Google पुस्तकें कई उदाहरण रखती हैं। "सेलको एन्कोडिंग" के लिए खोजें।

अन्य उदाहरण: देशों के लिए 2 या 3 पत्र एनकोडिंग, मुद्रा कोड के लिए 3-अक्षर एन्कोडिंग (GBP, USD, EUR)। लघु, आत्म-व्याख्यात्मक और नहीं बदलना (और उनके लिए एक आईएसओ है)।