ईएवी डेटाबेस से रिपोर्टिंग में कमियों को दूर करने के लिए कैसे?

Question

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

मैं वर्तमान में एक प्रणाली तैयार कर रहा हूं जहां इकाइयों में से एक के लिए फ़ील्ड डिजाइन/संकलन समय पर ज्ञात नहीं हैं और सिस्टम के अंतिम उपयोगकर्ता द्वारा परिभाषित किए जाते हैं। ईएवी इस आवश्यकता के लिए एक अच्छा फिट लगता है, लेकिन जिन समस्याओं के बारे में मैंने पढ़ा है, उनके कारण मैं इसे लागू करने में संकोच कर रहा हूं क्योंकि इस प्रणाली के लिए कुछ भारी रिपोर्टिंग आवश्यकताएं भी हैं। मैं सोचता हूं मैं इस के आसपास एक रास्ता लेकर आया हूं लेकिन एसओ समुदाय को सवाल उठाना चाहता हूं।

यह देखते हुए कि ठेठ सामान्यीकृत डेटाबेस (OLTP) अभी भी रिपोर्ट चलाने के लिए सबसे अच्छा विकल्प नहीं है, एक अच्छी प्रैक्टिस में "रिपोर्टिंग" डेटाबेस (ओलाप) होना प्रतीत होता है जहां सामान्यीकृत डेटाबेस से डेटा कॉपी किया जाता है, व्यापक पूछताछ के लिए व्यापक रूप से अनुक्रमित, और संभावित रूप से denormalized। क्या एक ही विचार ईएवी डिजाइन की कमियों के आसपास काम करने के लिए इस्तेमाल किया जा सकता है?

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

यदि आपके पास पूछताछ के लिए एक अलग रिपोर्टिंग डेटाबेस है तो ईएवी सिस्टम के साथ समस्याएं अधिकतर दूर हो जाती हैं?

संपादित करें: टिप्पणियों के लिए धन्यवाद। सिस्टम के बारे में महत्वपूर्ण बातों में से एक मैं इस पर काम कर रहा हूं कि मैं वास्तव में केवल एक इकाई के लिए ईएवी का उपयोग करने के बारे में बात कर रहा हूं, सिस्टम में सबकुछ नहीं।

सिस्टम का पूरा ज्ञान कई अलग-अलग स्रोतों से डेटा खींचने में सक्षम होना है जो समय से पहले ज्ञात नहीं हैं और डेटा को किसी विशेष इकाई के बारे में कुछ "सर्वश्रेष्ठ ज्ञात" डेटा के साथ आने के लिए क्रंच करते हैं। तो मैं जिन "फील्ड" से निपट रहा हूं वह बहु-मूल्यवान है और मुझे प्रत्येक के लिए इतिहास ट्रैक करने की भी आवश्यकता है। इसके लिए सामान्यीकृत डिज़ाइन 1 फ़ील्ड प्रति फ़ील्ड होता है जो किसी भी तरह से दर्दनाक तरीके से पूछताछ करता है।

यहाँ तालिका स्कीमा और नमूना डेटा मैं देख रहा हूँ (जाहिर है मैं क्या पर काम कर रहा हूँ से बदल लेकिन मैं यह बात अच्छी तरह से दिखाता है लगता है) कर रहे हैं:

EAV टेबल्स

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_Value 
------------------------------------------------------------------- 
- PersonId - Source - Field  - Value   - EffectiveDate - 
------------------------------------------------------------------- 
-  123 - CIA - HomeAddress - 123 Cherry Ln - 2010-03-26 - 
-  123 - DMV - HomeAddress - 561 Stoney Rd - 2010-02-15 - 
-  123 - FBI - HomeAddress - 676 Lancas Dr - 2010-03-01 - 
------------------------------------------------------------------- 

रिपोर्टिंग टेबल

Person_Denormalized 
---------------------------------------------------------------------------------------- 
- Id - Name  - HomeAddress - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
---------------------------------------------------------------------------------------- 
- 123 - Joe Smith - 123 Cherry Ln -     0.713 -    2010-03-26 - 
---------------------------------------------------------------------------------------- 

सामान्यीकृत डिजाइन

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_HomeAddress 
------------------------------------------------------ 
- PersonId - Source - Value   - Effective Date - 
------------------------------------------------------ 
-  123 - CIA - 123 Cherry Ln -  2010-03-26 - 
-  123 - DMV - 561 Stoney Rd -  2010-02-15 - 
-  123 - FBI - 676 Lancas Dr -  2010-03-01 - 
------------------------------------------------------ 

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

Answer 1

संक्षिप्त उत्तर - हाँ, एक रिपोर्टिंग डेटाबेस एक ईएवी से रिपोर्टिंग की समस्याओं को हल करने के लिए एक उचित दृष्टिकोण है डेटा मॉडल।

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

इस दृष्टिकोण की ताकत में से एक है कि एक ही तंत्र उस जगह में पहले से ही था कुछ उपयोगकर्ता पुन: उपयोग किया और रिपोर्टिंग कार्य करने के लिए लागू किया जा सकता के साथ काम कर सकता करने के लिए EAV मॉडल को बदलने के लिए किया गया था।

Answer 2

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

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

इसके साथ शुभकामनाएँ।

Answer 3

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

जब से तुम स्पष्ट रूप से समस्या की प्रकृति का श्रेय देना "इस योजना में किया जा रहा है", यह वास्तव में मुझे लगता है के रूप में यदि EAV के साथ समस्या यह वास्तव में जैसे EAV के कारण है।

असल में, इसके बारे में सोचने के लिए आओ: "एक प्रणाली जो उपयोगकर्ताओं को किसी भी प्रकार का डेटा स्टोर करने देती है" एक प्रणाली के बराबर है जो उपयोगकर्ताओं को केवल अपने रिवार्वर को परिभाषित करने की अनुमति देती है। लेकिन उस प्रणाली का कौन सा हिस्सा उपयोगकर्ताओं को प्रत्येक विशेषता पर बाधाओं को परिभाषित करने की अनुमति देता है? ओह, ईएवी भीड़ ने डेटा प्रबंधन के एक गैर-महत्वपूर्ण पहलू को याद किया है, ऐसा लगता है ...

Answer 4

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

आप एक EAV डीबी समय व्यतीत यह डिजाइनिंग का निर्माण कर रहे हैं, तो डिजाइन या तो कर सकते हैं या आपके आवेदन को तोड़ने और यह एक बुरा सपना को ठीक करने या एक खराब एक तैयार किया गया है के साथ सौदा करने की कोशिश कर रहा होगा।