डाटाबेस डिजाइन - एकाधिक लुकअप/एनम टेबल्स या एक बड़ी टेबल?

Question

मेरे पास कई टेबल हैं जो उनके अधिकांश कॉलम मानों के लिए लुकअप/एनम संदर्भ का उपयोग करती हैं। उदाहरण के लिए:
व्यक्ति तालिका - व्यक्ति आईडी | रेसकोड | HairColorCode | HairStyleCode | TeethConditionCode
स्थान तालिका - स्थान आईडी | आकार कोड | बाहरी रंगरोड | कंडीशनकोड
रेस, आकार, रंग, हालत, आदि जैसी चीजें कोड कोड तालिका के लिए विदेशी कुंजी संदर्भ होंगी। इस कोड तालिका में अन्य फ़ील्ड हैं लेकिन मेरे प्रश्न के लिए महत्वपूर्ण नहीं हैं। डेटाबेस एक सास एप्लिकेशन के लिए है जिसका अर्थ है कि प्रत्येक ग्राहक के पास रंग, दौड़, शर्तें इत्यादि की अपनी सूची हो सकती है। कुछ कोड हैं जो स्थिर होंगे जो ग्राहक बदल नहीं सकते हैं।

क्या 1 कोड तालिका या 2 प्रकार के कोड तालिकाओं (ग्राहक परिभाषित लोगों के लिए गतिशील कोडटेबल और एक परिवर्तन बदलने वालों के लिए स्टेटिक कोडटेबल) होना बेहतर है या मेरे पास प्रत्येक कोड प्रकार (रेसकोडटेबल, हेयरकॉलरटेबल, हालत, आदि) ?

जिस चीज के बारे में मैं सबसे ज्यादा चिंतित हूं, वह सब एसक्यूएल शामिल है। जिन व्यक्तियों के साथ मैं काम कर रहा हूं उनमें इन कोड गुणों में से 20+ हैं। 20 अलग-अलग तालिकाओं में शामिल होने पर प्रदर्शन में कोई अंतर होता है वीएस एक ही तालिका में 20 बार शामिल हो रहा है? एकाधिक तालिकाओं का मतलब है कि प्रत्येक तालिका छोटी होगी और लुकअप 'कम' लेना चाहिए। लेकिन एक भी टेबल होने से भी जल्दी हो सकता है। कोई सुझाव?

Answer 1

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

Answer 2

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

तो मैंने क्या सीखा?

• स्थिर मूल्यों के लिए, बस एक enum का उपयोग करें - यह बहुत तेज़ और अधिक सुविधाजनक है। यह निर्णय इस बात के आधार पर किया जाना चाहिए कि कितनी अन्य सारणी एक ही चर के संदर्भ में हो सकती हैं।
• जितना आप सोच सकते हैं उतने कम बनाने के बजाय कम लुकअप टेबल के साथ चिपके रहें। जॉय बहुत धीमे हैं।
• अपने आप को नेविगेट करने में मदद करने के लिए, डिज़ाइन डेटाबेस VIEWs। यह आपके जीवन को बहुत आसान बना देगा।
• बोनस के रूप में, यदि आप नहीं चाहते हैं कि आपके क्लाइंट कुछ टेबल (यानी आपके स्थिर वाले) को छूएं, या एनम कॉलम मानों को छूएं, तो आप MySQL (उदाहरण के लिए) कुछ कॉलम में परिवर्तन अक्षम करने के लिए ठीक-ठीक अनुमतियों का उपयोग कर सकते हैं कुछ तालिकाओं में। बहुत से लोगों को यह नहीं पता कि इन अनुमतियों को कितना लचीला मिल सकता है।

Answer 3

एक संभावित प्रदर्शन अंतर है।

केवल दो पंक्तियों वाली एक तालिका उन दो छोटी पंक्तियों के लिए कैश में बहुत सी जगहों से जुड़ती है।

यदि आपके पास एक ही तालिका में बहुत सारे लुकअप मान हैं, तो आप प्रभावी ढंग से उन मूल्यों को कैश में अधिक घनत्व से पैक करें।

Answer 4

इस विषय पर "पच्ची लुकअप टेबल" (संक्षेप में ओटीएलटी) विषय के तहत पिछले पंद्रह वर्षों की लंबाई में चर्चा की गई है। इस तरह के दृष्टिकोण के फायदे डेटाबेस नौसिखिया के लिए बाहर निकलते हैं। समय के साथ कमियां उभरती हैं। अधिक विचार-विमर्श को खोजने के लिए

• http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
• http://web.archive.org/web/20100130062850/http://www.dbazine.com/ofinterest/oi-articles/celko22

या searchOTLT के लिए: OTLT खामियों के लिए इन लिंक देखें।

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

उपयोगकर्ताओं को नए कोड TYPES पेश करने के लिए, और न केवल नए कोड VALUES, जो कीड़े का एक बड़ा बड़ा खुलता है। ईएवी पर चर्चा उपर्युक्त आलेख देखें। यह बहुत मोहक है, क्योंकि यह उपयोगकर्ताओं को अपनी अंतर्निहित डेटा संरचना तैयार करने की अनुमति देता है। यदि आप प्रदर्शन की उपेक्षा करते हैं, तो यह थोड़ी देर के लिए बहुत अच्छी तरह से काम करता है। उपयोगकर्ताओं या विषय विशेषज्ञों से डेटा संरचना सीखने के बिना आपको एक पूर्ण सामान्य डेटाबेस मिलता है।

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

(उसे संपादित "डाटा माइनिंग" बदलने के लिए "डेटा पुरातत्व" करने के लिए)