चर स्तंभों के साथ तालिका डिजाइन को कैसे संभालना है

Question

मेरे पास एक टेबल डिज़ाइन परिदृश्य है और एक गैर-डीबीए प्रकार के रूप में, उन रायों को पसंद करेंगे जिन पर अधिक मापनीय है।

मान लीजिए कि आपको एक छोटे से पड़ोस (200 घर) से शुरू होकर मेट्रो क्षेत्र के लिए घरों की जानकारी रिकॉर्ड करने के लिए कहा गया है, लेकिन अंततः 5000000+ घरों तक बढ़ रहा है।

आपको आधार जानकारी संग्रहीत करने की आवश्यकता है: ID # (एक अद्वितीय # हम एक अद्वितीय सूचकांक के रूप में उपयोग कर सकते हैं), Addr, शहर, राज्य, ज़िप। ठीक है, सरल तालिका इसे संभाल लेगी।

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

अंत में - प्रत्येक वर्ष अतिरिक्त कॉलम का # परिवर्तन होगा। 2 अतिरिक्त स्तंभों के साथ शुरू हो सकता है, फिर अगले वर्ष 6 पर जाएं, फिर 2 पर वापस जाएं।

इसलिए एक टेबल एप्रोच घर के टेबल में कस्टम जानकारी को कॉलम के रूप में जोड़ने का प्रयास करना है ताकि केवल एक टेबल हो।

लेकिन मेरे पास एक ऐसी स्थिति है जहां किसी ने इसके लिए तालिकाओं को रखा है:

"हाउस टेबल" कॉलम: आईडी, अतिरिक्त, शहर, राज्य, ज़िप - प्रति घर एक पंक्ति के साथ

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

"कस्टम जानकारी तालिका" कॉलम: आईडी, नाम, मान - जैसे दिखने वाली तालिका:

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

इसलिए प्रत्येक व्यक्तिगत घर रिकॉर्ड के लिए कई पंक्तियाँ हैं। हर साल जब वैकल्पिक जानकारी में बदलाव की आवश्यकता होती है, तो इस तालिका का शाब्दिक रूप से पुनर्निर्माण किया जाता है, इसलिए अगले वर्ष ऐसा लग सकता है:

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

आखिरकार आप 100,000 घर पंक्तियों को एक कर देते हैं और एक वर्ष में जानकारी के 10 अतिरिक्त टुकड़े होते हैं; दूसरी तालिका अब जानकारी की 1,000,000 पंक्तियाँ हैं, जिनमें से कई में अनावश्यक (विवरण) जानकारी है। समग्र रूप से डेटाबेस की आवश्यकताएं हैं कि लोगों को प्रति दिन हजारों बार घर की जानकारी + संबंधित कस्टम फ़ील्ड मान प्राप्त करने की आवश्यकता होगी।

इसलिए मेरा प्रश्न: क्या इसके बजाय यह बुरा (या भयानक) अभ्यास होगा:

क) कस्टम कॉलम के अधिकतम # पर अनुमान के साथ घर की मेज बिछाएं ("10" के माध्यम से "शायद" 1 ") और उन कस्टम मानों को घर की पंक्तियों में डालें।

या

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

धन्यवाद, आशा है कि यह समझ में आता है!

Comments

नमस्ते, आपने अपनी समस्या का प्रबंधन कैसे किया? मैं एक ही तरह के परिदृश्य में चल रहा हूं और मैं प्रति अतिरिक्त जानकारी के लिए एक संबंधपरक तालिका बना रहा हूं, और इसे "सिंगल टेबल" के रूप में देखा जा सकता है।

— बेंज

Answer 1

आपके पास बहुत अधिक 4 विकल्प हैं:

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

ईएवी - परिभाषा यह वह जगह है जहां आप या तो पूरी मेज या एक हिस्से (दूसरी तालिका में) को अपनी तरफ मोड़ते हैं। यह एक अच्छा विकल्प है यदि आपके पास पहले से ही एक संबंधपरक डेटाबेस है, जिसे आप आसानी से दूर नहीं कर सकते। आपके द्वारा दी गई कस्टम जानकारी तालिका उदाहरण EAV तालिका का एक अच्छा उदाहरण है।

XML स्तंभों के साथ मानक तालिकाएँ - यह सोचें कि NoSQL संबंधपरक तालिकाओं से मिलता है। XML स्तंभ में संग्रहीत डेटा किसी भी प्रारूप का हो सकता है, जो XML समर्थन करता है, जिसमें कई सहसंबद्ध उप-डेटा शामिल हैं। उन कॉलमों के लिए जिन्हें आप जानते हैं कि वे "नियमित" कॉलम हैं, उन्हें डेटा (अंतिम नाम, पता, शहर, राज्य, आदि) संग्रहीत करने के लिए उपयुक्त प्रकार के कॉलम के रूप में बनाया जा सकता है।

बहुत सारे अतिरिक्त स्तंभों के साथ मानक तालिकाएँ - आपके पास एक संबंधपरक डेटाबेस है, आप XML या EAV का उपयोग नहीं कर सकते हैं, और NoSQL एक विकल्प नहीं है। प्रत्येक प्रकार के बहुत सारे अतिरिक्त कॉलम जोड़ें। मुझे लगता है कि 30 या अधिक varchar, 30 या अधिक पूर्णांक, 15 या अधिक संख्याएँ होगी। और एक बार जब आप किसी मान के लिए एक कॉलम का उपयोग करते हैं , तो इसे फिर से उपयोग न करें । और कॉलम को भी डिलीट न करें ।

इन सभी समाधानों में से, मेरा अपना मत यह है कि आप अपने कोड और स्कीमा को कम से कम मात्रा में प्राप्त करने के साथ NoSQL या EAV दृष्टिकोण को सबसे अधिक सफल पाएंगे।

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

Comments

मैंने सुना है कि आप धुरी तालिकाओं या कुछ इस तरह का भी उपयोग कर सकते हैं

— अलेक्जेंडर मिल्स

Answer 2

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

हालाँकि, यह मुझे NoSQL डेटाबेस के लिए एक अच्छे उम्मीदवार की तरह लगता है ( http://en.wikipedia.org/wiki/NoSQL )। जबकि मैंने कभी इस तरह के डेटाबेस के साथ काम नहीं किया, आप जो वर्णन करते हैं वह एक विशिष्ट परिदृश्य है जो इस हल करता है।

Answer 3

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

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

इस दृष्टिकोण के साथ समस्या यह है, कि आपके पास कोई इतिहास नहीं है, लेकिन आप स्तंभ अनुरोधों को बदलने से पहले हर साल आसानी से एक प्रति बना सकते हैं।

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";

Answer 4

क्या आप उन सभी परिदृश्यों की गणना कर सकते हैं जिनके लिए आप इस डेटा को संग्रहीत करना चाहते हैं?

यदि तालिका में लागू किए जा सकने वाले स्तंभ संयोजनों की एक सीमित संख्या है, तो सभी स्तंभों पर लागू होने वाले सामान्य स्तंभों के साथ "आधार तालिका" को मॉडल करने का प्रयास करें, फिर अधिक तालिकाओं (किसी प्रकार की विरासत को लागू करने के लिए) बनाएं; इसे ERD और डेटाबेस डिज़ाइन में उपप्रकार / सुपरटाइप के रूप में जाना जाता है।)

प्रत्येक परिदृश्य के लिए एक तालिका, इस तरह से कम से कम आप तालिकाओं को साफ रखेंगे और आप "अंतिम नाम" कॉलम में संग्रहीत सड़क के पते से बचने में सक्षम होंगे ...

इस डिज़ाइन के प्रश्न पर एक नज़र डालें: /programming/554522/something-like-inheritance-in-database-design