डेटाबेस डिज़ाइन - खाली फ़ील्ड

Question

मैं वर्तमान में अपनी देव टीम के साथ एक समस्या पर बहस कर रहा हूं। उनका मानना ​​है कि खाली क्षेत्र बुरी खबर हैं। उदाहरण के लिए, यदि हमारे पास ग्राहक विवरण तालिका है जो विभिन्न देशों के ग्राहकों के लिए डेटा संग्रहीत करती है, और प्रत्येक देश में थोड़ा अलग पता कॉन्फ़िगरेशन होता है - साथ ही 1-2 अतिरिक्त फ़ील्ड, उदा। फ्रांसीसी ग्राहक विवरण एंट्री कोड, और फर्श/लेवल प्लस टाइटल फ़ील्ड (मैडमैम इत्यादि) के लिए विवरण भी स्टोर कर सकते हैं। दक्षिण अफ्रीका में एक सुरक्षा नंबर होगा। और इसी तरह।

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

मेरे सहयोगी का मानना ​​है कि हमारे पास अतिरिक्त डेटा के साथ एक अलग तालिका होनी चाहिए। जैसे customer_info_fr। लेकिन यह सीम पहली जगह में संयुक्त तालिका के उद्देश्य को पूरी तरह से हराने के लिए है।

तर्क यह है कि खाली फ़ील्ड/कॉलम खराब हैं - लेकिन मैं इस तर्क और पसंदीदा समाधान के लिए या उसके विरुद्ध डेटाबेस डिज़ाइन सिद्धांतों के संदर्भ में औचित्य खोजने के लिए संघर्ष कर रहा हूं।

एक और विकल्प एक अलग मिनी ईएवी तालिका है जो parent_id, key, val फ़ील्ड के साथ अतिरिक्त डेटा संग्रहीत करता है। या मुख्य ग्राहक_डेटा तालिका में अतिरिक्त डेटा को अतिरिक्त_डाटा कॉलम में क्रमबद्ध करने के लिए।

मुझे लगता है कि मैं उलझन में हूं क्योंकि मैं जो चर्चा कर रहा हूं वह 3 एनएफ द्वारा कवर नहीं किया गया है, जो मैं आम तौर पर डेटा को कैसे व्यवस्थित करने के संदर्भ के रूप में उपयोग करता हूं।

तो मेरे सवाल का विशेष रूप से: -

आप प्रत्येक रिकॉर्ड (उदाहरण के लिए 1-2 विभिन्न क्षेत्रों) क्या आगे बढ़ने के लिए सबसे अच्छा तरीका है के लिए डेटा में मामूली प्रसरण है?

Answer 1

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

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

Answer 2

यही नलिका फ़ील्ड निम्न है: "डेटा उपलब्ध/लागू नहीं है"।

एसक्यूएल की अधिकांश प्रोग्रामिंग भाषाओं की तुलना में शून्य की एक अलग धारणा है, इसलिए एसक्यूएल की नल अक्सर एक गलतफहमी अवधारणा होती है।

Answer 3

मुझे आपके सहयोगी के औचित्य में रुचि होगी कि खाली फ़ील्ड खराब क्यों हैं। जहां तक ​​मुझे पता है, खाली या शून्य फ़ील्ड स्वयं में और अपने आप में बुरा नहीं हैं। यदि आपके पास एक कॉलम के लिए बहुत सारे खाली डेटा मान हैं जिन पर आप एक महत्वपूर्ण इंडेक्स डालने की योजना बना रहे हैं, तो आप अन्य विकल्पों पर विचार करना चाहेंगे। यह किसी भी कॉलम के लिए जाता है जहां आपके पास वास्तव में बहुत सारे डुप्लिकेट रिकॉर्ड होते हैं और कॉलम के डुप्लिकेट रिकॉर्ड lower the cardinality के रूप में इंडेक्स की आवश्यकता होती है, जिससे इंडेक्स कम उपयोगी होते हैं। आपके मामले में, मुझे यह कोई मुद्दा नहीं दिख रहा है।

इस प्रकार का डेटा के लिए, आप की संभावना एक VARCHAR या वैसे भी पाठ स्तंभ किसी तरह का है, जो डेटाबेस में चर लंबाई क्षेत्र हैं का उपयोग कर रहे हैं। इससे कोई फर्क नहीं पड़ता कि आपका क्षेत्र डेटा या खाली से भरा है, फिर भी आप एक चर-लंबाई कॉलम के ऊपरी हिस्से को ले जा रहे हैं (जो सामान्य परिस्थितियों में चिंता करने योग्य नहीं है)। तो फिर, आरडीबीएमएस में कोई फर्क नहीं पड़ता।

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

Answer 4

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

आपका सहयोगी 6 वें सामान्य फॉर्म के लिए सड़क पर कुछ ऐसा प्रस्तावित कर रहा है, जहां सभी तालिकाओं में प्राथमिक कुंजी और अधिकतर एक कॉलम होता है। केवल इस तरह की एक स्कीमा में हमारे पास customer_info_fr नामक सारणी नहीं होगी। यह सामान्य नहीं है। कई देशों में पते में ENTRY_CODE शामिल हो सकते हैं। तो हमें address_entry_codes और address_floor_numbers की आवश्यकता होगी। address_building_number और address_building_name का उल्लेख नहीं करना, क्योंकि कुछ स्थानों को संख्या और अन्य नाम से पहचाना जाता है।

यह तार्किक डिजाइन के रूप में पूरी तरह सटीक और सत्य है। एक भौतिक परिप्रेक्ष्य से हां यह तेह चक है! सबसे सरल क्वेरी - select * from addresses - एक बहु-तालिका में शामिल हो जाता है, और उसमें बाहरी शामिल होता है। निरर्थक कॉलम कठोर सच्चाई के साथ बदसूरत डिजाइन को सुलझाने का एक तरीका है, "आप भौतिकी के नियम तोड़ सकते हैं"। निरर्थक कॉलम हमें अलग-अलग डेटा सेट को एकल तालिका में संयोजित करने की अनुमति देते हैं, यद्यपि नल को संभालने की लागत पर (वे डेटा पुनर्प्राप्ति, इंडेक्स उपयोग, गणित इत्यादि को प्रभावित कर सकते हैं)।

Answer 5

जो कुछ भी आप करते हैं, ईएवी मार्ग पर न जाएं। यह एक खराब प्रदर्शन करने वाले डेटाबेस के लिए एक नुस्खा है, कुछ खाली क्षेत्रों की तुलना में कहीं भी बदतर है।

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

हालांकि, अगर आप कभी भी अधिकारियों से पूछताछ नहीं करेंगे और फ़ील्ड अलग समझ लेंगे, तो उन्हें एक अलग तालिका में रखें।