डेटाबेस टेबल के बीच 1-से-1 संबंधों का उपयोग कब करें?

Question

एक डीबी डिजाइन सवाल: आप 1 से 1 संबंध तालिकाओं का उपयोग करने का निर्णय कब लेते हैं?

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

तकनीकी रूप से, आप केवल एक ही तालिका में सभी कॉलम डाल सकते हैं क्योंकि उनका रिश्ते 1-से-1 है।

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

तो, यदि मैं उपयोगकर्ता तालिका और उपयोगकर्ता प्रोफाइल तालिका तैयार करना चाहता हूं, तो क्या यह मेरे लिए एक टेबल में बस इतना बेहतर है?

Answer 1

एकमात्र बार जब मैंने 1 से 1 रिश्ते का उपयोग किया है, तो मैं चाहता हूं कि यह बहुरूपता से कई वस्तुओं से संबंधित हो।

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

Answer 2

केवल उपयोगकर्ता तालिका में रिकॉर्ड्स की सभी संख्याओं के लिए UserProfile तालिका में फ़ील्ड की आवश्यकता नहीं होती है। उदाहरण के लिए यदि आपके पास 3,000,000 उपयोगकर्ता थे, लेकिन उनमें से केवल 3,000 में उपयोगकर्ता प्रोफाइल हैं, तो उन्हें विभाजित करने के लिए समझदारी हो सकती है (नल कॉलम के पूरे समूह से बचने के लिए।)

हालांकि अब बढ़ते डेटाबेस की गति और सस्ते लागत के साथ एक दिन भंडारण, यह वास्तव में इस कारण से उन्हें विभाजित करने में बहुत अंतर नहीं करता है ...

Answer 3

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

तालिका में डेटा संबंधित होने पर आपको 1-से-1 का उपयोग करना चाहिए, लेकिन उसी उद्देश्य के लिए नहीं है। (शायद बेहतर शब्द कहा जा सकता है)

इसके अलावा यह चीजों को ढूंढना आसान बना सकता है। 75 कॉलम वाले टेबल को देखने से ज्यादा मुझे नफरत नहीं है।

Answer 4

मैंने हाल ही में एक देखा है जहां आपके पास एक तालिका थी, जिसमें अधिकांश डेटा था, फिर एक और टेबल जिसमें बहुत सारे और बहुत सारे वैकल्पिक डेटा थे।

दूसरी तालिका में पंक्तियों का एक तिहाई था, लेकिन तीन गुना स्तंभ थे।

यह कुछ साल पहले किया गया था कॉलम में बहुत सारे नल से बचें - यानी खाली जगह।

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

Answer 5

क्लासिक कारण शून्य कॉलम से बचने के लिए है।

कॉलम में एक नल मान होने से स्पष्ट (रखरखाव योग्य) एसक्यूएल लिखना कठिन हो सकता है। @Ovid ने इस here के बारे में लिखा है, Chris Date के काम पर चित्रण।

Answer 6

यह एक सीधी प्रतिलिपि है और इस धागे में आज पॉप अप किया गया है, लेकिन यह यहां भी उपयोगी लगता है। Is there ever a time where using a database 1:1 relationship makes sense?

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

एक और पोस्टर ने 1: 1 को सामान्यीकृत नहीं किया, मैं कुछ परिस्थितियों में विशेष रूप से उप-प्रकार से असहमत हूं। मान लें कि मेरे पास एक कर्मचारी तालिका है और प्राथमिक कुंजी उनका एसएसएन है (यह एक उदाहरण है, आइए बहस को बचाएं कि यह एक अच्छी कुंजी है या नहीं, किसी अन्य धागे के लिए)। कर्मचारी अलग-अलग प्रकार के हो सकते हैं, अस्थायी या स्थायी कह सकते हैं और यदि वे स्थायी हैं तो उनके पास ऑफिस फोन नंबर की तरह अधिक फ़ील्ड भरने होंगे, जो कि टाइप = 'स्थायी' है, जो केवल शून्य नहीं होना चाहिए। एक तीसरे सामान्य रूप डेटाबेस में कॉलम केवल कुंजी पर निर्भर होना चाहिए, जिसका मतलब कर्मचारी है, लेकिन यह वास्तव में कर्मचारी और प्रकार पर निर्भर करता है, इसलिए 1: 1 संबंध पूरी तरह से सामान्य है, और इस मामले में वांछनीय है। यह अत्यधिक स्पैस टेबल भी रोकता है, अगर मेरे पास सामान्य रूप से 10 कॉलम होते हैं, लेकिन केवल कुछ प्रकार के लिए 20 अतिरिक्त कॉलम होते हैं।

Answer 7

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

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

मुझे जानते हैं अगर किसी भी बेहतर समाधान

Answer 8

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

में 0 या 1 संबंधित रिकॉर्ड होंगे।

शेन डी और अन्य परिदृश्यों का वर्णन करते हैं जो इस तथ्य का लाभ उठाते हैं।