क्या एक-से-एक संबंध सामान्यीकृत है?

गौर करें कि हमारे पास रिकॉर्ड के लिए सांख्यिकीय डेटा का एक बड़ा सेट है; जैसे 20-30 INTकॉलम। क्या पूरे सेट को एक तालिका में रखना बेहतर है क्योंकि वे सभी एक रिकॉर्ड से संबंधित हैं या एक-से-एक संबंध से जुड़ी एक और तालिका बना रहे हैं।

पूर्व के लाभ से बचने JOINऔर संबंधित रिकॉर्ड के लिए सभी सांख्यिकीय डेटा तक त्वरित पहुंच है।

उत्तरार्द्ध का लाभ स्तंभ को साफ रखना है। पहला कॉलम रीड-इंटेंसिव है, और दूसरा राइट-इंटेंसिव। बेशक, मुझे लगता है कि प्रदर्शन पर इसका कोई महत्वपूर्ण प्रभाव नहीं है, क्योंकि मैं रो-लेवल ब्लॉकिंग के साथ InnoDB का उपयोग करता हूं।

सामान्य तौर पर मैं जानना चाहता हूं कि क्या एकल रिकॉर्ड के लिए डेटा के विभिन्न सेटों को अलग करना व्यावहारिक है?

— Googlebot
स्रोत

'सामान्यीकृत' का अर्थ पहले सामान्य रूप (1NF) है और यह संबंधपरक मॉडल की एक मूलभूत आवश्यकता है। 'पूरी तरह से सामान्यीकृत' का अर्थ है 5NF या इससे अधिक। आपके प्रस्तावित 'वन-टू-वन रिलेशनशिप' टेबल में आपके वर्तमान के मुकाबले उच्च सामान्य रूप में (संभवतः 6NF में भी) होने का बेहतर मौका है क्योंकि यह विघटित हो गया है! आपकी मौजूदा तालिका क्या सामान्य रूपों को संतुष्ट करती है?

— onedaywhen

@onedaywhen कई अन्य लोगों की तरह मैं भी कदम से कदम सामान्यीकरण का पालन नहीं करता हूं, क्योंकि कभी-कभी डी-सामान्यकरण भी सहायक होता है। सामान्य तौर पर, पूरे डेटाबेस में 3NF - 5NF (मुझे हमेशा 4NF के साथ समस्या है!) के बीच सामान्यीकरण स्तर होना चाहिए

— Googlebot

जवाबों:

यदि यह सामान्यीकरण के नियमों के भीतर फिट बैठता है, तो 1: 1 रिश्तों को सामान्य किया जा सकता है (परिभाषा द्वारा!) - दूसरे शब्दों में, 1: 1 रिश्तों के बारे में कुछ भी नहीं है जो सामान्य रूपों का पालन करना उनके लिए असंभव बना देता है।

1: 1 संबंधों की व्यावहारिकता के बारे में आपके प्रश्न का उत्तर देने के लिए, ऐसे समय होते हैं जब यह पूरी तरह से उपयोगी निर्माण होता है, जैसे कि जब आपके पास अलग-अलग विधेय (कॉलम) के साथ उपप्रकार होते हैं।

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

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

तो आप देख सकते हैं, कभी-कभी ड्राइवर का प्रदर्शन होता है, कभी-कभी यह मॉडल शुद्धता होती है, या केवल घोषणा स्कीमा नियमों का पूरा लाभ उठाने की इच्छा होती है।

— जोएल ब्राउन
स्रोत

You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.

उन्हें अलग करने से प्रदर्शन में सुधार कैसे होता है (यह मानकर कि कॉलम हर बार मुख्य तालिका तक पहुंचते हैं)?

— गिली

@ गिल्ली - अगर आपकी धारणा सही थी तो यह मामला लागू नहीं होगा। बड़े और बार-बार आवश्यक स्तंभों को अलग करने से अधिक पंक्तियों को एक पृष्ठ पर फिट होने की अनुमति मिलती है, जिससे आमतौर पर उपयोग किए जाने वाले स्तंभों की तेजी से पुनर्प्राप्ति की अनुमति मिलती है। स्पष्ट रूप से इस्तेमाल किए गए स्तंभों के साथ-साथ अलग-अलग स्तंभों को पढ़ना धीमा हो जाएगा क्योंकि इसमें शामिल होना आवश्यक है।

— जोएल ब्राउन

मैं डिजाइन कारणों (चिंताओं को अलग करना, कोड का पुन: उपयोग करना) के लिए आमतौर पर उपयोग किए जाने वाले कॉलम के साथ अलग करना चाहता हूं। क्या किसी ने इस तरह के जुड़ने की लागत का अनुमान लगाया है? क्या वे नगण्य हैं या कुछ ऐसा है जिसकी मुझे लंबे समय तक चिंता करनी चाहिए?

— गिली

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

— जोएल ब्राउन

मैंने किया, और आश्चर्यजनक परिणाम मिले: dba.stackexchange.com/q/74693/4719 मैं मानता हूं कि यह सामान्यीकरण का एक विशिष्ट उदाहरण नहीं है, लेकिन यह उजागर नहीं करता है कि जॉइन (अभी भी) बहुत महंगे हैं।

— गिली

आप एक बड़ी तालिका को दो में तोड़ने के लिए एक से एक मैपिंग का उपयोग करने के प्रमुख कारण उदाहरण के लिए प्रदर्शन कारणों से कर सकते हैं:

क) तालिका में बाइनरी / क्लॉब / बूँद डेटा अक्सर एक्सेस की गई तालिका में होता है इसलिए बड़े कॉलम को अलग-अलग तरीके से सौंपने के बाद से प्रदर्शन धीमा हो जाता है।

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

हालाँकि कई पूर्णांक कॉलम होने से टेबल को अलग-अलग टेबल में तोड़ने और उन्हें क्वेरी करने के अतिरिक्त प्रयास का औचित्य नहीं है।

— स्टीफन सेन्कोमागो मुसोके
स्रोत

मुद्दे के स्पष्टीकरण के लिए बहुत अच्छा बिंदु!

— Googlebot