समेकित करने के लिए कुल मिलाकर या नहीं, यह डेटाबेस स्कीमा डिज़ाइन प्रश्न

Question

है यदि आप न्यूनतम/अधिकतम/औसत क्वेरी कर रहे हैं, तो क्या आप कच्ची तालिका में पंक्तियों की एक श्रृंखला में समेकन तालिकाओं का उपयोग करना पसंद करते हैं?

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

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

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

क्या वैसे भी मैं दोनों दुनिया के सर्वश्रेष्ठ हो सकता हूं?

Answer 1

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

1. आप किसी भी तरह से आप चाहते हैं की क्वेरी के लिए लचीलेपन का एक बहुत कुछ है। इससे पहले कि हम को विशिष्ट योग, बनाना था, लेकिन अब एक घन हमारे सभी प्रश्नों का उत्तर देता है।
2. विस्तृत डेटा की तुलना में घन में संग्रहण बहुत छोटा है।
3. क्यूब का निर्माण और प्रसंस्करण कम समय लेता है और से डेटाबेस सर्वर पर लोड कम करता है।

कुछ कान्स:

1. आसपास इमारत क्यूब्स और सीखने MDX एक सीखने की अवस्था है।
2. हमें क्यूब के साथ स्वचालित काम करने के लिए कुछ टूल बनाना था।

अद्यतन: आप MySQL का उपयोग कर रहे हैं, आप Pentaho Mondrian पर एक नज़र है, जो एक खुला स्रोत OLAP समाधान MySql का समर्थन करता है लग सकता है। मैंने कभी इसका इस्तेमाल नहीं किया है, इसलिए मुझे नहीं पता कि यह आपके लिए काम करेगा या नहीं। यह जानने में रुचि होगी कि यह आपके लिए काम करता है या नहीं।

Answer 2

मैं हमेशा कच्चे डेटा की तरफ झुकता हूं। एक बार समेकित, आप वापस नहीं जा सकते हैं।
हटाने के साथ कुछ भी करने के लिए - जब तक कि समेकित डेटा सेट का सबसे सरल न हो, आप डेटा को कच्चे पर वापस सही/स्थानांतरित नहीं कर सकते हैं।

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

Answer 3

यह एक अच्छी प्राथमिक कुंजी (यानी [user_id, used_date, used_time] चुनने में मदद करता है)। निरंतर user_id के लिए यह used_date पर एक श्रेणी-शर्त करने के लिए बहुत तेज़ है।

लेकिन जैसे ही तालिका बढ़ती है, आप अपनी तालिका-आकार को [user_id, used_date] जैसी तालिका में एकत्र करके घटा सकते हैं। प्रत्येक श्रेणी के लिए जहां समय-समय पर कोई फर्क नहीं पड़ता है, तब आप उस तालिका का उपयोग कर सकते हैं। तालिका-आकार को कम करने का एक अन्य तरीका पुराने डेटा को संग्रहीत करना है जिसे आप अब पूछताछ नहीं करते हैं (अनुमति दें)।