सबसे पहले, ये दो अलग-अलग डेटा मॉडल हैं जो अलग-अलग उद्देश्यों के लिए उपयुक्त हैं।
ऐसा कहा जा रहा है, मुझे उम्मीद है कि दूसरा मॉडल एकत्रीकरण के लिए तेज़ होगा, क्योंकि डेटा अधिक कॉम्पैक्ट रूप से पैक किया जाता है, इसलिए कम I/O की आवश्यकता होती है:
- पहले मॉडल में GROUP BY को पूर्ण . द्वारा संतुष्ट किया जा सकता है इंडेक्स पर स्कैन करें
{size, price}. जब डेटा RAM में फ़िट होने के लिए बहुत बड़ा हो तो अनुक्रमणिका का विकल्प बहुत धीमा होता है। - दूसरे मॉडल में क्वेरी को पूर्ण तालिका स्कैन द्वारा संतुष्ट किया जा सकता है। किसी अनुक्रमणिका की आवश्यकता नहीं है।
चूंकि पहले दृष्टिकोण के लिए टेबल + इंडेक्स की आवश्यकता होती है और दूसरे को सिर्फ टेबल की आवश्यकता होती है, दूसरे मामले में कैश का उपयोग बेहतर होता है। यहां तक कि अगर हम कैशिंग की उपेक्षा करते हैं और दूसरे मॉडल में तालिका के साथ पहले मॉडल में सूचकांक (तालिका के बिना) की तुलना करते हैं, तो मुझे संदेह है कि सूचकांक तालिका से बड़ा होगा, क्योंकि यह भौतिक रूप से size रिकॉर्ड करता है। और बी-पेड़ों के लिए विशिष्ट रूप से अप्रयुक्त "छेद" हैं (हालांकि यह तालिका के लिए भी सच है यदि यह क्लस्टर किया गया
)।
और अंत में, दूसरे मॉडल में इंडेक्स रखरखाव ओवरहेड नहीं है, जो INSERT/UPDATE/DELETE प्रदर्शन को प्रभावित कर सकता है।
इसके अलावा, आप केवल एक पंक्ति वाली एक अलग तालिका में SUM और COUNT को कैशिंग करने पर विचार कर सकते हैं। जब भी मुख्य तालिका में कोई पंक्ति डाली जाती है, अद्यतन की जाती है या हटाई जाती है, तो ट्रिगर के माध्यम से SUM और COUNT दोनों को अपडेट करें। फिर आप केवल SUM और COUNT को विभाजित करके, आसानी से वर्तमान AVG प्राप्त कर सकते हैं।
लेकिन आपको वास्तव में माप . करना चाहिए सुनिश्चित करने के लिए डेटा की प्रतिनिधि मात्रा पर।
चूंकि आपकी क्वेरी में WHERE क्लॉज नहीं है, इसलिए सभी पंक्तियों को स्कैन किया जाएगा। अनुक्रमणिका केवल तालिका की पंक्तियों का एक अपेक्षाकृत छोटा उपसमूह प्राप्त करने के लिए उपयोगी होती है (और कभी-कभी केवल अनुक्रमणिका स्कैन ) एक मोटे नियम के रूप में, यदि तालिका में 10% से अधिक पंक्तियों की आवश्यकता है, तो अनुक्रमणिकाएँ मदद नहीं करेंगी और अनुक्रमणिका उपलब्ध होने पर भी DBMS अक्सर पूर्ण तालिका स्कैन का विकल्प चुनेंगे।
