अगले और पिछले तत्व के लिए प्रश्नों का अनुकूलन

वोट
28

मैं सबसे अच्छा तरीका है एक पूर्ण जिज्ञासा चलाए बिना एक रिकार्ड के अगले और पिछले रिकॉर्ड को पुनः प्राप्त करने के लिए देख रहा हूँ। मैं जगह में एक पूरी तरह से लागू समाधान है, और पता करने के लिए क्या कोई बेहतर दृष्टिकोण इस बाहर करने के लिए कर रहे हैं कि क्या करना चाहते हैं।

मान लीजिए कि हम एक काल्पनिक फल बेचनेवाला के लिए एक वेब साइट का निर्माण कर रहे हैं। अपने HTML पृष्ठों के अलावा, हर हफ्ते, वह अपने साइट पर विशेष प्रस्तावों की सूची प्रकाशित करना चाहता है। वह एक वास्तविक डेटाबेस तालिका में रहते हैं उन प्रस्तावों चाहता है, और उन तीन तरीकों से प्रस्तावों को सॉर्ट करने में सक्षम होना चाहिए।

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

वैकल्पिक पाठ http://www.pekkagaiser.com/stuff/Sort.gif?

जाहिर है, के लिए अगले बटन टमाटर, कक्षा मैं सेब, कक्षा 1 पहला उदाहरण में होना चाहिए था नाशपाती, वर्ग मैं द्वितीय और तृतीय में कोई भी में।

विस्तार को ध्यान में रखते काम है एक प्रश्न हर बार चलने के बिना अगले और पिछले आइटम निर्धारित करने के लिए , केवल उपलब्ध जानकारी के रूप में सूची की तरह आदेश के साथ (चलो कहते हैं कि हम किसी GET पैरामीटर के माध्यम से है कि प्राप्त करते हैं ?sort=offeroftheweek_price, और सुरक्षा के प्रभाव की अनदेखी) ।

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

मेरी सीएमएस में मेरे वर्तमान दृष्टिकोण कुछ मैं कैश छँटाई नाम है उपयोग कर रहा है। जब एक सूची भरी हुई है, मैं नाम के एक तालिका में रिकॉर्ड में आइटम पदों की दुकान sortingcache

name (VARCHAR)             items (TEXT)

offeroftheweek_unsorted    Lettuce; Tomatoes; Apples I; Apples II; Pears
offeroftheweek_price       Tomatoes;Pears;Apples I; Apples II; Lettuce
offeroftheweek_class_asc   Apples II;Lettuce;Apples;Pears;Tomatoes

जाहिर है, itemsस्तंभ वास्तव में संख्यात्मक आईडी से भर जाता है।

विवरण पृष्ठ में, मैं अब उचित का उपयोग sortingcacheरिकॉर्ड, लाने itemsस्तंभ, और उसमें विस्फोट, वर्तमान आइटम आईडी के लिए खोज, और पिछले और अगले पड़ोसी लौट आते हैं।

array(current   => Tomatoes,
      next      => Pears,
      previous  => null
      );

यह स्पष्ट रूप से महंगा है, केवल रिकॉर्ड की एक सीमित संख्या के लिए काम करता है और अनावश्यक डेटा बनाता है, लेकिन मान लें कि असली दुनिया में हैं, सूची बनाने के लिए क्वेरी बहुत महंगा है (यह है), हर विस्तार दृश्य में चल रहा से बाहर है सवाल है, और कुछ कैशिंग की जरूरत है।

मेरे सवाल:

  • क्या आपको लगता है कि इस प्रश्न के आदेश बदलती के लिए पड़ोसी रिकॉर्ड पता लगाने के लिए एक अच्छा अभ्यास है?

  • आप प्रदर्शन और सादगी के मामले में बेहतर प्रथाओं को जानते हो? आप कुछ है कि यह पूरी तरह से अप्रचलित बनाता है पता है?

  • प्रोग्रामिंग सिद्धांत रूप में, इस समस्या के लिए एक नाम है?

  • नाम छंटाई कैश उचित और इस तकनीक के लिए समझा जा सकता है है?

  • वहाँ किसी भी मान्यता प्राप्त, आम इस समस्या को हल करने के लिए पैटर्न हैं? वे क्या कहलाते हैं?

नोट: मेरा प्रश्न सूची निर्माण, या कैसे विवरण दृश्य प्रदर्शित करने के लिए के बारे में नहीं है। उन सिर्फ उदाहरण हैं। मेरा प्रश्न है बुनियादी कार्यक्षमता एक रिकार्ड के पड़ोसियों का निर्धारण करने के लिए जब एक फिर से क्वेरी असंभव है की, और सबसे तेज और सबसे सस्ता तरीका है वहाँ पाने के।

अगर कुछ स्पष्ट नहीं है, एक टिप्पणी छोड़ और मैं स्पष्ट करेगा।

एक इनाम शुरू - हो सकता है वहाँ इस पर कुछ अधिक जानकारी बाहर नहीं है।

22/02/2010 को 12:06
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


11 जवाब

वोट
-3

तो अगर आप दो कार्यों है:

  1. मदों की क्रमबद्ध सूची का निर्माण (द्वारा क्रम भिन्न है का चयन करता है)
  2. प्रत्येक आइटम के बारे में विवरण (संभव कैशिंग के साथ डेटाबेस से विवरण का चयन करें) दिखा।

समस्या क्या है?

पुनश्च: यदि आदेश दिया सूची बहुत बड़ा हो सकता है तो आप सिर्फ पेजर कार्यक्षमता लागू की जरूरत है। वहाँ अलग अलग कार्यान्वयन जैसे आप क्वेरी में "सीमा 5" जोड़ सकते हैं और "शो अगले 5" प्रदान बटन करना चाह सकते हैं हो सकता है,। जब इस बटन दबाया जाता है, जैसे हालत "कहां मूल्य <0.89 सीमा 5" जोड़ा गया है।

22/02/2010 को 15:04
का स्रोत उपयोगकर्ता

वोट
16

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

एक तालिका बनाएं अगले और प्रत्येक प्रस्ताव और प्रत्येक प्रकार के विकल्प के लिए पिछले धारण करने के लिए। (वैकल्पिक रूप से, आप प्रस्ताव तालिका में संग्रहीत कर सकता है आप हमेशा तीन प्रकार विकल्प होंगे अगर - क्वेरी गति अपने डेटाबेस denormalize करने के लिए एक अच्छा कारण है)

तो अगर आप इन स्तंभों के लिए होता है:

  • क्रमबद्ध प्रकार (क्रमित किए बिना, मूल्य, क्लास और मूल्य वर्णन)
  • प्रस्ताव आईडी
  • पिछला आईडी
  • अगला आईडी

ऑफ़र विवरण पृष्ठ के लिए विवरण जानकारी डेटाबेस से पूछे जाता है, NextID और PrevID परिणाम का हिस्सा होगा। तो अगर आप केवल एक विवरण पृष्ठ के लिए एक क्वेरी की आवश्यकता होगी।

हर बार एक प्रस्ताव, डाला जाता है अद्यतन या नष्ट कर दिया है, तो आप एक प्रक्रिया है जो sorttype मेज की अखंडता / सटीकता की पुष्टि करता है चलाने के लिए की आवश्यकता होगी।

22/02/2010 को 20:20
का स्रोत उपयोगकर्ता

वोट
1

मुझे यकीन है कि क्या मैं सही से समझ नहीं हूँ, इसलिए यदि नहीं, तो बस मुझे बताओ;)

मान लीजिए कि, कि गिवेंस क्रमबद्ध सूची और मौजूदा उस सूची में ऑफसेट के लिए क्वेरी कर रहे हैं करते हैं, यानी हम एक है $queryऔर एक $n

प्रश्नों को कम करने के लिए एक बहुत ही स्पष्ट समाधान, एक बार में सभी डाटा को लाना होगा:

list($prev, $current, $next) = DB::q($query . ' LIMIT ?i, 3', $n - 1)->fetchAll(PDO::FETCH_NUM);

यही कारण है कि बयान, पिछले वर्तमान और वर्तमान छंटाई क्रम में डेटाबेस से अगले तत्वों को हासिल करेगा और अनुकूल चरों में संबंधित जानकारी डालता है।

लेकिन इस समाधान के रूप में भी आसान है, मुझे लगता है कि मैं कुछ गलत समझा।

07/02/2011 को 20:31
का स्रोत उपयोगकर्ता

वोट
2

मैं भी इस एक के साथ बुरे सपने लिया है। आपका वर्तमान दृष्टिकोण भी 10k आइटम सूचियां लिए सबसे अच्छा समाधान हो रहा है। सूची दृश्य की आईडी कैशिंग http सत्र में और उसके बाद प्रदर्शित करने के लिए उपयोग कर रहा है कि (वर्तमान उपयोगकर्ता के लिए व्यक्तिगत) पिछली / अगली। यह अच्छी तरह से काम करता है, खासकर जब वहाँ फ़िल्टर करने और सिर्फ 3 के बजाय वस्तुओं की प्रारंभिक सूची सॉर्ट करने के लिए भी कई तरीके हैं
इसके अलावा, पूरे आईडी सूची आप एक प्रदर्शित करने के लिए मिलता है भंडारण के द्वारा "you are at X out of Y"प्रयोज्य बढ़ाने पाठ।
JIRA के पिछली / अगली

वैसे, यह क्या है JIRA रूप में अच्छी तरह से करता है।

सीधे आपके सवालों के जवाब के लिए:

  • हाँ, यह अच्छी आदत है, क्योंकि यह किसी भी जोड़ा कोड जटिलता के बिना मापता है जब आपके फिल्टर / छंटाई और आइटम प्रकार और अधिक जटिल कौवा। मैं एक उत्पादन प्रणाली में यह उपयोग कर रहा हूँ "अनंत" फिल्टर / तरह बदलाव के साथ 250k लेख के साथ। 1000 तक संचित करने योग्य आईडी ट्रिमिंग भी एक संभावना के बाद से उपयोगकर्ता सबसे शायद पिछला पर क्लिक करें कभी नहीं होगा या अगले 500 से अधिक बार (वह संभवत: वापस जाने के लिए और खोज को परिष्कृत या पृष्ठ पर अंक लगाना होगा) है।
  • मैं एक बेहतर तरीका की जानकारी नहीं है। लेकिन अगर एक तरह जहां सीमित है और यह एक सार्वजनिक साइट (कोई http सत्र के साथ) था तो मैं सबसे शायद denormalize चाहते हैं।
  • पता नहीं।
  • हाँ, छँटाई कैश अच्छा लगता है। अपने प्रोजेक्ट में मैं इसे "खोज परिणामों पर पिछली / अगली" या "खोज परिणामों पर नेविगेशन" कहते हैं।
  • पता नहीं।
07/02/2011 को 21:04
का स्रोत उपयोगकर्ता

वोट
2

सामान्य तौर पर, मैं अनुक्रमित से डेटा denormalize। वे एक ही पंक्तियों में संग्रहित किया जा सकता है, लेकिन मैं लगभग हमेशा अपने परिणाम आईडी पुनः प्राप्त है, तो डेटा के लिए एक अलग यात्रा करते हैं। यह बहुत ही सरल डेटा कैशिंग बनाता है। यह PHP में बहुत महत्वपूर्ण है, जहां विलंबता कम है और बैंडविड्थ अधिक है, लेकिन इस तरह की रणनीति बहुत उपयोगी है आप इस तरह के एक AJAX वेबसाइट है, जहां साइट के ज्यादा जावास्क्रिप्ट में प्रदान की गई है के रूप में, उच्च प्रतीक्षा अवधि, कम बैंडविड्थ आवेदन किया है नहीं है।

मैं हमेशा परिणामों की सूची को कैश, और खुद को अलग परिणाम है। कुछ भी एक सूची क्वेरी के परिणामों को प्रभावित करता है, तो सूची परिणामों के कैश ताजा है। कुछ भी खुद को प्रभावित करता है परिणाम हैं, उन विशेष परिणाम ताजा कर रहे हैं। यह मैं सब कुछ को पुनर्जीवित करने, प्रभावी कैशिंग में जिसके परिणामस्वरूप बिना या तो एक अद्यतन करने के लिए अनुमति देता है।

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

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

आपके सवालों के जवाब के लिए विशेष रूप:

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

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

09/02/2011 को 08:00
का स्रोत उपयोगकर्ता

वोट
0

वहाँ त्वचा लौकिक बिल्ली के रूप में यह करने के लिए के रूप में कई तरीके हैं। तो यहाँ मेरा के एक जोड़े हैं।

यदि आपकी मूल क्वेरी महंगा है, आप जो कहते हैं कि यह है, तो एक और तालिका संभवतः एक स्मृति तालिका आपके महंगा के परिणामों के साथ यह पॉप्युलेट बना सकते हैं और शायद ही कभी मुख्य क्वेरी चलाते हैं।

यह दूसरी तालिका तो हर दृश्य पर पूछे जा सकता है और छंटाई उचित सॉर्ट क्रम स्थापित करने के रूप में सरल है।

के रूप में की आवश्यकता है पहले मेज से परिणामों के साथ दूसरी तालिका फिर से आबाद है, इस प्रकार डेटा ताजा रखने के लिए, लेकिन महंगा क्वेरी के उपयोग को न्यूनतम।

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

डीसी

11/02/2011 को 05:19
का स्रोत उपयोगकर्ता

वोट
0

मूलभूत पूर्वानुमान:

  • स्पेशल साप्ताहिक हैं
  • हम साइट बार बार ... शायद दैनिक बदलने के लिए उम्मीद कर सकते हैं?
  • हम आकाश एक API के साथ डेटाबेस के लिए अपडेट को नियंत्रित या ट्रिगर्स के माध्यम से प्रतिक्रिया कर सकते हैं

साइट एक दैनिक आधार पर बदलता है, तो मेरा सुझाव है कि सभी पृष्ठों स्थिर रात भर उत्पन्न कर रहे हैं। के माध्यम से एक तरह से आदेश दोहराता के लिए एक क्वेरी और सभी संबंधित पृष्ठों बनाता है। यहां तक ​​कि अगर वहाँ गतिशील तत्व हैं, बाधाओं है कि आप उन्हें स्थैतिक पृष्ठ तत्वों को शामिल करके पता कर सकते हैं कर रहे हैं। यह इष्टतम पेज सेवा और कोई डेटाबेस लोड प्रदान करेगा। वास्तव में, आप संभवतः अलग पन्नों और पिछला / अगले तत्व है कि पन्नों में शामिल किए गए हैं उत्पन्न कर सकता है। यह सॉर्ट करने के लिए 200 तरीके के साथ उन्मादपूर्ण हो सकता है लेकिन 3 के साथ मैं इसके बारे में एक बड़ा प्रशंसक रहा हूँ।

?sort=price
include(/sorts/$sort/tomatoes_class_1)
/*tomatoes_class_1 is probably a numeric id; sanitize your sort key... use numerics?*/

यह संभव नहीं है किसी कारण के लिए, मैं याद का सहारा था। मेम्कैश बात की इस तरह के लिए लोकप्रिय है (यमक!)। कुछ डेटाबेस के लिए धक्का दिया जाता है, तो आप सही मूल्यों के साथ अपने कैश अद्यतन करने के लिए एक ट्रिगर जारी कर सकते हैं। फिर से लिंक के रूप में उपयुक्त (this.next.prev = this.prev, आदि) - उसी तरह आप अगर होगा जैसे कि आप अपने अद्यतन आइटम 3 जुड़ा हुआ सूचियों में ही अस्तित्व में में ऐसा करें। कि से, जब तक आपके कैश परिपूर्ण नहीं है, तो आप एक प्राथमिक कुंजी फैशन में स्मृति से सरल मूल्यों खींच हो जाएगा।

इस विधि का चयन करें और अद्यतन / डालने तरीकों पर कुछ अतिरिक्त कोडिंग लगेगा, लेकिन यह काफी कम से कम होना चाहिए। अंत में, आप देख रहे होंगे [id of tomatoes class 1].price.next। उस कुंजी अपने कैश में है, तो सोने की। यदि नहीं, तो कैश और प्रदर्शन में सम्मिलित करें।

  • क्या आपको लगता है कि इस प्रश्न के आदेश बदलती के लिए पड़ोसी रिकॉर्ड पता लगाने के लिए एक अच्छा अभ्यास है? हाँ। यह उम्मीद आगामी अनुरोध पर नज़र-Aheads प्रदर्शन करने के लिए बुद्धिमान है।
  • आप प्रदर्शन और सादगी के मामले में बेहतर प्रथाओं को जानते हो? आप कुछ है कि यह पूरी तरह से अप्रचलित बनाता है पता है? उम्मीद है कि इसके बाद के संस्करण
  • प्रोग्रामिंग सिद्धांत रूप में, इस समस्या के लिए एक नाम है? अनुकूलन?
  • नाम "छंटाई कैश" उचित और इस तकनीक के लिए समझा जा सकता है है? मैं एक विशिष्ट उपयुक्त नाम का यकीन नहीं है। यह कैशिंग है, यह एक तरह की एक कैश है, लेकिन मुझे यकीन है कि मुझे बता कि तुम एक "छँटाई कैश" तुरंत समझ व्यक्त होता है नहीं कर रहा हूँ।
  • वहाँ किसी भी मान्यता प्राप्त, आम इस समस्या को हल करने के लिए पैटर्न हैं? वे क्या कहलाते हैं? कैशिंग?

क्षमा करें मेरी पीछा जवाब तरह का बेकार हैं, लेकिन मुझे लगता है कि मेरी कथा समाधान काफी उपयोगी होना चाहिए।

11/02/2011 को 18:13
का स्रोत उपयोगकर्ता

वोट
0

आप को बचा सकता है पंक्ति संख्या में आदेश दिया सूचियों के विचारों , और आप (current_rownum -1) और (current_rownum +1) पंक्ति संख्या के तहत सूची में पिछले और अगले आइटम तक पहुँच सकता है।

12/02/2011 को 14:01
का स्रोत उपयोगकर्ता

वोट
0

समस्या / datastructur द्वि-दिशात्मक ग्राफ के नाम पर है या आप कह सकते हैं आप कई जुड़ा हुआ सूचियों मिल गया है।

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

यदि आप एक (द्वि) दिशात्मक ग्राफ के रूप में यह के बारे में सोच रहे हैं, तो आप जेसिका के जवाब के साथ चलते हैं। मुख्य समस्या यह है कि वहाँ आदेश अपडेट महंगा संचालन कर रहे हैं।

 Item Next Prev
   A   B     -
   B   C     A
   C   D     B
   ...

आप नए आदेश ए, सी, बी, डी करने के लिए एक आइटम स्थिति को बदलने के हैं, तो आप 4 पंक्तियां अपडेट करना होगा।

13/02/2011 को 02:20
का स्रोत उपयोगकर्ता

वोट
4

मैं कुछ हद तक जेसिका के लिए इसी तरह की एक विचार है। हालांकि, बजाय अगले और पिछले तरह आइटम के लिंक के भंडारण के लिए, आप प्रत्येक प्रकार प्रकार के लिए सॉर्ट क्रम की दुकान। पिछले या अगले रिकॉर्ड ढूंढने के लिए, बस के साथ SortX = currentSort ++ या SortX = currentSort-- पंक्ति मिलता है।

उदाहरण:

Type     Class Price Sort1  Sort2 Sort3
Lettuce  2     0.89  0      4     0
Tomatoes 1     1.50  1      0     4
Apples   1     1.10  2      2     2
Apples   2     0.95  3      3     1
Pears    1     1.25  4      1     3

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

अर्थात

once_per_day
  add/delete/update all records
  recalculate sort orders

उम्मीद है कि यह उपयोगी है।

13/02/2011 को 03:30
का स्रोत उपयोगकर्ता

वोट
0

क्षमा याचना अगर मैं गलत समझा है, लेकिन मुझे लगता है कि आप उपयोगकर्ता के बीच सर्वर से पहुँचता आदेश दिया सूची बनाए रखने के लिए चाहते हैं। यदि हां, तो आपका जवाब अच्छी तरह से अपने कैशिंग रणनीति और प्रौद्योगिकी में के बजाय डेटाबेस क्वेरी / स्कीमा अनुकूलन में झूठ सकता है।

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

आप यह भी संकेत नहीं है कि कितने प्रकार क्रमपरिवर्तन वहाँ वास्तविक दुनिया में हैं, जैसे आप प्रति उपयोगकर्ता अलग-अलग सूचियों को कैश करने की जरूरत है, या आप विश्व स्तर पर तरह क्रमचय प्रति कैश और फिर फ़िल्टर कर सकते हैं आप PHP के माध्यम से की जरूरत नहीं है क्या ?. उदाहरण आप दे में, मैं बस दोनों क्रमपरिवर्तन और दुकान, जिनमें से दो मैं () सत्र डेटा में unserialize करने की जरूरत कैश चाहते हैं।

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

क्या यह वापस आ जा रहा है, यह कि कितने समय में संशोधित किया गया था डेटा के आकार पर निर्भर करेगी उपयुक्त है, और क्या कैशिंग प्रौद्योगिकियों अपने सर्वर पर उपलब्ध हैं।

13/02/2011 को 15:47
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more