यहाँ एक विचार है। जब अंतिम उपयोगकर्ता देखने के लिए डेटा का चयन करता है, तो इसके बजाय जब किराना विक्रेता नए ऑफ़र सम्मिलित/अपडेट करता है, तो आप महंगे संचालन को एक अद्यतन में उतार सकते हैं। यह सॉर्ट डेटा को संभालने के लिए एक गैर-गतिशील तरीके की तरह लग सकता है, लेकिन यह गति बढ़ा सकता है। और, जैसा कि हम जानते हैं, प्रदर्शन और अन्य कोडिंग कारकों के बीच हमेशा एक समझौता होता है।
प्रत्येक ऑफ़र और प्रत्येक प्रकार के विकल्प के लिए अगला और पिछला रखने के लिए एक तालिका बनाएं। (वैकल्पिक रूप से, आप इसे ऑफ़र तालिका में संग्रहीत कर सकते हैं यदि आपके पास हमेशा तीन प्रकार के विकल्प होंगे - क्वेरी गति आपके डेटाबेस को असामान्य करने का एक अच्छा कारण है)
तो आपके पास ये कॉलम होंगे:
- क्रमबद्ध प्रकार (बिना क्रमित, मूल्य, श्रेणी और मूल्य विवरण)
- ऑफ़र आईडी
- पिछला आईडी
- अगली आईडी
जब डेटाबेस से ऑफ़र विवरण पृष्ठ के लिए विस्तृत जानकारी मांगी जाती है, तो NextID और PrevID परिणामों का हिस्सा होंगे। तो आपको प्रत्येक विवरण पृष्ठ के लिए केवल एक प्रश्न की आवश्यकता होगी।
हर बार जब कोई प्रस्ताव डाला जाता है, अद्यतन किया जाता है या हटाया जाता है, तो आपको एक ऐसी प्रक्रिया चलाने की आवश्यकता होगी जो सॉर्टटाइप तालिका की अखंडता/सटीकता को मान्य करे।
