बेहतर डेटाबेस डिज़ाइन क्या है: अधिक टेबल या अधिक कॉलम?

Question

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

उन्होंने तर्क दिया कि यह डिज़ाइन अधिक कुशल था और लचीला। शायद यह अधिक लचीला है, लेकिन मैं इसकी दक्षता पर टिप्पणी करने के लिए योग्य नहीं हूं। यहां तक ​​कि यदि यह अधिक कुशल है, तो मुझे लगता है कि उन लाभों को अतिरिक्त जटिलता से अधिक किया जा सकता है।

तो, क्या अधिक कॉलम के साथ कम तालिकाओं पर कम कॉलम वाले अधिक तालिकाओं के लिए कोई महत्वपूर्ण लाभ हैं?

Answer 1

मैं अंगूठे मैं पालन जब डेटाबेस है, जो मुझे लगता है कि मदद करने के लिए इस तरह निर्णय लेने के लिए किया जा सकता को डिजाइन करने के कुछ ही काफी सरल नियमों ....

1. फ़ेवर सामान्य है। Denormalization सभी आवश्यक व्यापारिकताओं के साथ अनुकूलन का एक रूप है, और इस तरह से इसे YAGNI दृष्टिकोण से संपर्क किया जाना चाहिए।
2. सुनिश्चित करें कि डेटाबेस का संदर्भ देने वाला क्लाइंट कोड उस स्कीमा से पर्याप्त रूप से decoupled है जो इसे पुनर्विक्रय करने के लिए क्लाइंट (ओं) का एक बड़ा नवीनीकरण की आवश्यकता नहीं है।
3. प्रदर्शन या क्वेरी जटिलता के लिए स्पष्ट लाभ प्रदान करते समय denormalize से डरो मत।
4. स्कीमा, के कोर को denormalizing के बजाय denormalization लागू करने के लिए विचार या डाउनस्ट्रीम टेबल का उपयोग करें, जब डेटा वॉल्यूम और उपयोग परिदृश्य के लिए अनुमति देते हैं।

इन नियमों का सामान्य परिणाम यह है कि प्रारंभिक डिज़ाइन कॉलम पर तालिकाओं का पक्ष लेगा, अनावश्यकता को दूर करने पर ध्यान केंद्रित करने के साथ। चूंकि परियोजना की प्रगति होती है और denormalization अंक की पहचान की जाती है, समग्र संरचना एक संतुलन की ओर विकसित होगी जो सीमित मूल्यवानता और कॉलम प्रसार के साथ अन्य मूल्यवान लाभों के बदले में समझौता करती है।

Answer 2

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

Answer 3

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

जब सिस्टम विकसित किया जा रहा है, तो आप कुछ हिस्सों को 'असामान्य' मान सकते हैं यदि आप इसे सुधार के रूप में देखते हैं।

Answer 4

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

मुझे लगता है कि मेरा जवाब क्या होगा, अपने सर्वोत्तम निर्णय का उपयोग करें।

Answer 5

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

Jeff wrote स्टैक ओवरफ्लो के डिज़ाइन के बारे में इसके बारे में थोड़ा सा। Dare Obasanjo तक जेफ लिंक पोस्ट भी देखें।

Answer 6

कम कॉलम के साथ टेबल होने के फायदे हैं, लेकिन आप भी ऊपर अपने परिदृश्य को देखो और इन सवालों के जवाब की जरूरत है:

ग्राहक 1 से अधिक पता करने की अनुमति दी जा सकता है? यदि नहीं, तो पते के लिए एक अलग तालिका आवश्यक नहीं है। यदि ऐसा है, तो एक अलग तालिका उपयोगी हो जाती है क्योंकि आप आसानी से सड़क के नीचे आवश्यकतानुसार अधिक पते जोड़ सकते हैं, जहां तालिका में और कॉलम जोड़ना अधिक कठिन हो जाता है।

Answer 7

इसके लिए कई पक्ष हैं, लेकिन एक अनुप्रयोग दक्षता परिप्रेक्ष्य से मोटे टेबल कई बार अधिक कुशल हो सकते हैं। यदि आपके पास डीबी को ऑपरेशन करने के लिए कॉलम के गुच्छा के साथ कुछ टेबल हैं, तो लॉक बनाने का मौका है, लॉक की अवधि के लिए अधिक डेटा अनुपलब्ध हो जाता है। यदि ताले पृष्ठ और तालिकाओं तक बढ़ जाते हैं (अच्छी तरह उम्मीद है कि टेबल नहीं :)) आप देख सकते हैं कि यह सिस्टम को धीमा कर सकता है।

Answer 8

प्रश्न के रूप में संभवतः कम से कम कॉलम का उपयोग करके भारी लाभ हैं। लेकिन तालिका में बड़ी संख्या हो सकती है। Jeff इस पर कुछ भी कहता है।

असल में, सुनिश्चित करें कि आप क्वेरी करते समय आपको अधिक से अधिक पूछने की आवश्यकता नहीं है - प्रश्नों का प्रदर्शन सीधे आपके द्वारा पूछे जाने वाले कॉलम की संख्या से संबंधित है।

Answer 9

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

Answer 10

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

मुझे शहर की मेज रखने का लाभ नहीं दिखता है जब तक कि अपने आप में ऐसे शहर नहीं हैं जिनकी आप परवाह करते हैं। या यदि आप अपने उपयोगकर्ताओं के लिए उपलब्ध शहरों की संख्या सीमित करना चाहते हैं।

नीचे की रेखाएं इस तरह के फैसले हैं कि आप दक्षता के लिए शूटिंग शुरू करने से पहले आवेदन को स्वयं ही विचार में ले लें। IMO।

Answer 11

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

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

Answer 12

अन्य सभी की तरह: यह निर्भर करता है।

स्तंभ गणना बनाम तालिका गणना के संबंध में कोई कठोर और तेज़ नियम नहीं है।

यदि आपके ग्राहकों को एकाधिक पते होने की आवश्यकता है, तो इसके लिए एक अलग तालिका समझ में आता है। यदि आपके पास सिटी कॉलम को अपनी तालिका में सामान्य करने का वास्तव में अच्छा कारण है, तो वह भी जा सकता है, लेकिन मैंने इसे पहले नहीं देखा है क्योंकि यह एक नि: शुल्क फॉर्म फ़ील्ड (आमतौर पर) है।

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

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

Here's Jeff's post विषय पर।

Answer 13

एक पूरी तरह से सामान्यीकृत डिज़ाइन (यानी, "अधिक टेबल्स") अधिक लचीला, बनाए रखने में आसान है, और डेटा के डुप्लिकेशंस से बचाता है, जिसका अर्थ है कि आपकी डेटा अखंडता लागू करने के लिए बहुत आसान हो जाएगी।

वे सामान्यीकृत करने के शक्तिशाली कारण हैं। मैं पहले सामान्यीकृत करना चुनता हूं, और फिर विशिष्ट तालिका के बाद केवल यह दिखाता है कि प्रदर्शन एक मुद्दा बन रहा था।

मेरा अनुभव यह है कि असली दुनिया में, आप उस बिंदु तक नहीं पहुंचेंगे जहां बहुत बड़े डेटा सेट के साथ भी denormalization आवश्यक है।

Answer 14

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

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

Answer 15

हम्म।

मुझे लगता है कि यह एक धो है और आपके विशेष डिजाइन मॉडल पर निर्भर करता है। निश्चित रूप से उन इकाइयों को कारक बनाएं जिनके पास अपनी खुद की तालिका में कुछ फ़ील्ड हैं, या जिन संस्थाओं की मेकअप संभवतः आपके आवेदन की आवश्यकताओं में परिवर्तन के रूप में बदल जाएगी (उदाहरण के लिए - मैं किसी भी तरह से पता लगाऊंगा, क्योंकि इसमें बहुत से फ़ील्ड हैं, लेकिन मैं 'डी विशेष रूप से ऐसा करें अगर आपको लगता है कि आपको विदेशी देश के पते को संभालने की आवश्यकता होगी, जो कि एक अलग रूप का हो सकता है। फोन नंबरों के साथ ही)।

उस ने कहा, जब आप इसे काम कर रहे हैं, तो प्रदर्शन पर नजर रखें। यदि आपने एक इकाई को बाहर निकाला है जिसके लिए आपको बड़ी, महंगे जुड़ने की आवश्यकता है, तो हो सकता है कि वह उस तालिका को मूल में वापस घुमाने के लिए एक बेहतर डिज़ाइन निर्णय बन जाए।

Answer 16

जब आप अपना डेटाबेस डिज़ाइन करते हैं, तो आपको डेटा के अर्थ से जितना संभव हो उतना करीब होना चाहिए और आपके आवेदन की आवश्यकता नहीं है!

एक अच्छा डेटाबेस डिज़ाइन परिवर्तन के बिना 20 वर्षों से अधिक समय तक खड़ा होना चाहिए।

एक ग्राहक के पास कई एड्रेस हो सकते हैं, यह वास्तविकता है। यदि आपने तय किया है कि आपका आवेदन पहली रिलीज के लिए एक विज्ञापन तक सीमित है, तो यह चिंता है कि आपके आवेदन का डिज़ाइन डेटा नहीं है!

एकाधिक कॉलम के बजाय एकाधिक तालिका रखना बेहतर है और यदि आप अपनी क्वेरी को सरल बनाना चाहते हैं तो दृश्य का उपयोग करना बेहतर है।

अधिकतर समय में आपके पास नेटवर्क प्रदर्शन के बारे में एक डेटाबेस के साथ प्रदर्शन समस्या होगी (एक पंक्ति परिणाम के साथ श्रृंखला क्वेरी, प्राप्त करने वाले कॉलम की आवश्यकता नहीं है, आदि) आपकी क्वेरी की जटिलता के बारे में नहीं।

Answer 17

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

Answer 18

इतने सारे प्रेरणादायक और अच्छी तरह से आधारित उत्तरों को देखने के लिए अच्छा है।

मेरा उत्तर होगा (दुर्भाग्य से): यह निर्भर करता है।

दो मामले: * यदि आप एक डेटामैडल बनाते हैं जिसका उपयोग कई सालों से किया जाना है और इस प्रकार संभवतः कई भविष्य में बदलावों को प्रभावित करना है: अधिक टेबल और कम पंक्तियों और सुंदर सख्त सामान्यीकरण के लिए जाएं। * अन्य मामलों में आप अधिक सारणी-कम पंक्तियों या कम सारणी-अधिक पंक्तियों के बीच चयन कर सकते हैं। खासकर इस विषय के लिए अपेक्षाकृत नए लोगों के लिए यह अंतिम दृष्टिकोण अधिक सहज और समझने में आसान हो सकता है।

ऑब्जेक्ट उन्मुख दृष्टिकोण और अन्य विकल्पों के बीच चयन के लिए मान्य है।