2010-07-27 12 views
7

मान लीजिए मैं अपने डेटाबेस में निम्न तालिकाओं है:क्या अनावश्यक संबंधों का उपयोग करना बुरा है?

tables http://www.freeimagehosting.net/uploads/a5ef036857.png

अब मेरी सभी प्रश्नों कंपनी मेज पर निर्भर करते हैं। क्या यह मेरे एसक्यूएल प्रश्नों को सरल बनाने के लिए कंपनी टेबल पर हर दूसरे टेबल को एक अनावश्यक संबंध देने का एक बुरा अभ्यास है?

संपादित करें 1: पृष्ठभूमि एक ढांचे के साथ उपयोग समस्या है। Django: limiting model data देखें।

संपादित करें 2: कोई टुपल अपनी कंपनी को नहीं बदलेगा।

संपादित करें 3: मैं mysql क्वेरी नहीं लिखता। मैं एक अमूर्त परत (django) का उपयोग करें।

+0

शब्द "रिलेशनशिप" का अर्थ यह नहीं है कि आप इसका क्या अर्थ रखते हैं। संबंधपरक डेटाबेस मॉडल में ए * संबंध * अधिकांश लोगों द्वारा तालिका को कॉल करने के अनुरूप होता है। अलग-अलग तालिकाओं में डेटा के बीच संबंधों के साथ इसका कोई लेना-देना नहीं है। – sqlvogel

+0

हाँ, आप सही हैं। मैंने इसे सही कर दिया है। – svenwltr

+0

@SvenWalter कृपया कोड ब्लॉक ('

') में तालिका के साथ प्रश्न अपडेट करें क्योंकि बाहरी छवि फ़ाइल अब उपलब्ध नहीं है। मैं एसई में उचित तालिकाओं के दर्द का दर्द साझा नहीं करता हूं (देवताओं को कभी भी इसे उपलब्ध कराने पर कठोर नहीं होता है), लेकिन कम से कम हम उन्हें बाहरी उपकरणों पर भरोसा करने के बजाय कोड ब्लॉक के साथ अनुकरण कर सकते हैं। –
                        
                            
    ADTC
                                
                            
                        
                    

उत्तर

7

यह खराब अभ्यास है क्योंकि आपके अनावश्यक डेटा को स्वतंत्र रूप से अद्यतन किया जाना चाहिए और इसलिए अनावश्यक रूप से। एक प्रक्रिया जो त्रुटि के लिए संभावित से भरा हुआ है। (यहां तक ​​कि स्वचालित कैस्केडिंग को अलग से असाइन और रखरखाव किया जाना चाहिए)

इस संबंध को पेश करके आप प्रभावी ढंग से अपने डेटाबेस को denormalize। प्रदर्शन के लिए कभी-कभी डिमॉर्मलाइजेशन आवश्यक होता है लेकिन आपके प्रश्न से ऐसा लगता है कि आप अपने एसक्यूएल को सरल बना रहे हैं।

सार करने के लिए अन्य तंत्र का उपयोग अपने डेटाबेस की जटिलता: दृश्य, संग्रहित Procs, UDFs

+0

कई आरडीबीएम के पास कैस्केडिंग अपडेट हैं। कंपनी तालिका में कंपनी आईडी को बदलने से संदर्भित सभी तालिकाओं को कैस्केड किया जाएगा। – siride

+1

सरडाइड: यह एक अच्छा मुद्दा है लेकिन आपके लिंक की कैस्केडबिलिटी को बनाए रखना अभी भी एक अतिरिक्त रखरखाव कदम है जिसे करना है और इसे सही ढंग से किया जाना है। सरल मेरी किताब में बेहतर है। अपनी विदेशी कुंजी के साथ चिपके रहें और अपने प्रश्नों में अतिरिक्त जॉइन के साथ रहें। –

+0

मुझे लगता है कि यह एक बुरा विचार है। आपकी मदद के लिए धन्यवाद ... मुझे एक और समाधान मिलना है। – svenwltr

4

क्या यह मेरे अन्य प्रश्नों को सरल बनाने के लिए कंपनी तालिका में एक अन्य (अनावश्यक) संबंध देने का एक बुरा अभ्यास है?

हाँ, बिल्कुल, के रूप में यह है जब आप कंपनी के लिए कंपनी या अनुभाग के लिए संबंधों ग्राहक को अद्यतन हर अनावश्यक संबंध को अद्यतन करने का मतलब होगा - और अगर आप किसी भी तरह के अद्यतन याद आती है, अब आप एक डेटाबेस अनावश्यक डेटा से भरा है। यह एक बुरा denormalization है।


यदि आपका बिंदु केवल अपने SQL को सरल बनाना है, तो "डेटा को साथ लाने" के विचारों का उपयोग करने पर विचार करें। यहाँ एक राय यह है कि अनुबंध में company_id खींचती द्वारा, ग्राहक के माध्यम से शामिल होने के लिए:

create view contract_customer as 
select 
    a.*, 
    b.contract_id, b.company_id 
from 
    contract a 
    join customer b on (a.customer_id = b.customer_id); 

इस में शामिल होने के लिए सरल है, लेकिन क्यों यह अधिक से अधिक दोहराने? इसे एक बार लिखें, और फिर अन्य प्रश्नों में दृश्य का उपयोग करें।

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

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

2

तुम्हारा मतलब अगर हर मेज पर एक कंपनी स्तंभ जोड़ने, यह एक बुरा विचार है। यह डेटा अखंडता के मुद्दों की संभावना को बढ़ाएगा (यानी यह एक टेबल में बदल जाता है लेकिन अन्य 6 जहां इसे चाहिए)।

-1

यह 'प्रदर्शन' के लिए आपकी कार्यात्मक आवश्यकताओं पर निर्भर करता है। क्या आपका आवेदन भारी मांग को संभालने जा रहा है? सरलीकृत जॉइन प्रदर्शन का दावा करता है। हार्डवेयर के अलावा सस्ता है और बारी-बारी का समय महत्वपूर्ण है।

और अधिक गहरा आप डेटाबेस सामान्य रूपों में जाना - आप गणना

+0

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

4

पर अंतरिक्ष लेकिन भारी बचाने तुम सच में चीजों को आसान बनाने के लिए की जरूरत है, यह वह जगह है, जहां एक View (या एकाधिक बार देखा गया) काम में आएगा।

अपने कर्मचारी दृश्य में कंपनी के लिए एक स्तंभ होने खराब सामान्यीकृत उपलब्ध कराने यह खंड पर एक में शामिल होने से ली गई है नहीं होगा।

1

मैं ओपी के मामले में नहीं कहूंगा, लेकिन कभी-कभी यह उपयोगी होता है (जैसे गोटो;)।

एक उपाख्यान:

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

5

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

संबंधित मुद्दे