व्यावहारिक रूप से डेटा की "बड़े पैमाने पर" राशि को स्टोर करने का तरीका जो शायद ही कभी बदलता है?

Question

पूर्व-गणना लुकअप टेबल या कुछ और के संदर्भ में सोचें। किस बिंदु पर मेरे आवेदन में हार्डकॉन्गिंग मानों के बजाय डेटाबेस का उपयोग करना अधिक समझ में आता है? मान बदलने वाले नहीं हैं, और वे अच्छी तरह से रखरखाव डेवलपर्स से अलग हो गए हैं। 100 मान, 1k, 10k, 100k? मैं लगभग 40k मान संग्रहीत करना चाहता हूं। अभी यह एक मशीन-जनरेटेड switchस्टेटमेंट है (जिसके बारे में VS2010 दुखी है)।

संपादित करें:

अगर किसी को उत्सुकता है, तो यहां बताया गया है कि मैंने यह कैसे किया: मेरा डेटा दो सौ k- तत्व फ्लोट एरेज़ में आकर्षक था, इसलिए मैंने यही किया। डेटा जनरेट करने में लगभग 20 सेकंड का समय लगा, इसलिए मैंने एक बार ऐसा किया, और बाइनरीफॉरमेटर के साथ एक एम्बेडेड संसाधन में इसे क्रमबद्ध किया। डेटा को अनपैक करने में एप्लिकेशन स्टार्टअप पर लगभग 5 मिलीसेकंड लगते हैं, और लगभग 45,000x गुणा डेटाबेस कार्यान्वयन को मैं प्रतिस्थापित कर रहा था (ये हार्ड-कोडेड मान पहले संग्रहीत किए गए थे)।

Answer 1

मेरा सुझाव डेटा को किसी फ़ाइल या डेटाबेस तालिका में रखना है। यदि गति कोई समस्या नहीं है, तो रन समय पर फ़ाइल या डेटाबेस (डेटाबेस बेहतर है) को क्वेरी करें। यदि मेमोरी कोई समस्या नहीं है, लेकिन आप कुछ गति चाहते हैं, तो प्रोग्राम शुरू होने पर डेटा को मेमोरी में लोड करें। C # में आप एक हैश-टेबल का उपयोग और सरणी, सूची या (सबसे अच्छा विकल्प) कर सकते हैं और आपके पास रनटाइम (यानी getDataValue (string keyToValue)) के लिए आवश्यक डेटा वापस करने की एक विधि है।

मैं आपको सलाह दूंगा कि आप स्विच स्टेटमेंट का उपयोग न करें क्योंकि इसे बनाए रखना बहुत मुश्किल होगा और इसके परिणामस्वरूप एक बड़ा एक्सरे होगा।

हैश-टेबल जैसे http://support.microsoft.com/kb/309357

Comments

यह आखिरकार मैंने क्या किया है: मेरे अपडेट किए गए पोस्ट की जांच करें।

— ब्रायन बोएचर

डेटाबेस सुझाव के लिए +1। डेटाबेस बड़े डेटा वॉल्यूम को संग्रहीत करने के लिए बनाए जाते हैं और आपको उन्हें बहुत तेज़ी से लाने की अनुमति देते हैं।

— NoChance

Stackoverflow.com/questions/301371/… पर देखें कि हैशटेबल के बजाय इसके लिए शब्दकोश का उपयोग करना बेहतर क्यों है। YMMV

— क्रिस मैककी

Answer 2

व्यक्तिगत रूप से, मैं किसी भी राशि के डेटा को स्टोर करने के लिए ठीक हूं, एप्लिकेशन में हार्डकोड किया गया है, जब तक कि एक विशेष तैनाती या हॉटफिक्स के लिए इसे ट्वीक करने की कोई आवश्यकता नहीं है।

हालाँकि, C # स्विच स्टेटमेंट का उपयोग करते हुए डेटा को स्टोर करना और एक्सेस करना बुरा व्यवहार है, क्योंकि कसकर कपल्स डेटा स्टोरेज और डेटा एक्सेस मॉडल में हैं और इसका मतलब केवल एक विधि एक्सेस विधि (स्विच पैरामीटर द्वारा) है।

मैं डेटा को एक हैशटेबल या डिक्शनरी में संग्रहीत करना पसंद करूँगा, और डेटा को पुनः प्राप्त करने के लिए अलग-अलग कक्षाएं प्रदान करूँगा, और एक बार लुक-अप शब्दकोशों की आबादी।

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

इस तरह के अपघटन का एक अच्छा लाभ यह है कि आप अपने डेटा पर कई संख्याओं को लागू कर सकते हैं, बिना XXXk लाइनों को छूने के बिना, उस डेटा को परिभाषित करता है।

Comments

मैंने कुछ उदाहरणों के साथ उत्तर दिया है।

— वलेरा कोलुपाएव

Answer 3

एक 40k लाइन स्विच स्टेटमेंट थोड़ा संदिग्ध है। मुझे लगता है कि आपको अभी भी क्वेरी संचालन सही करने की आवश्यकता है? क्या आपने डेटा एनकैप्सुलेट करने की कोशिश की है? फिर प्रदर्शन का परीक्षण करने के लिए संग्रह पर क्वेरी संचालन करने के लिए LINQ का उपयोग करें। स्टॉपवॉच जैसे टाइमर के साथ यूनिट परीक्षण चलाकर कुछ ठोस समय प्राप्त करें । फिर, अगर आपको लगता है कि यह सिर्फ काम कर सकता है। देखें कि प्रदर्शन उपयोगकर्ताओं के लिए स्वीकार्य है या नहीं।

Answer 4

मुझे दो बार इस तरह की आवश्यकता हुई है। एप्लिकेशन को बिना डेटाबेस सेटअप / एक्सेस के साथ स्टैंडअलोन होने के लिए डिज़ाइन किया गया था। दोनों ही मामलों में मैंने डेटा स्टोर करने के लिए XML फाइलों का इस्तेमाल किया। पहले एक में, जो कि 2.0 फ्रेमवर्क पर था, मैंने डेटा देखने के लिए पुराने स्टाइल XML पार्सिंग कॉल का उपयोग किया। नए के लिए, 3.5 फ्रेमवर्क पर, मैंने जो आवश्यक था उसे खोजने के लिए LINQ to XML का उपयोग किया। दोनों ही मामलों में, कक्षाओं में डेटा तक पहुंच को छोटा कर दिया गया था।

Answer 5

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

जब भी DB का उपयोग न करने की समस्या हो तो DB -it पर स्विच करने की संख्या के लिए समस्या बन जाती है।

Comments

मैं इस विचार की सराहना करता हूं कि मेरा इंटरफ़ेस कार्यान्वयन को बाधित करता है: यह सबसे निश्चित रूप से करता है। कार्यक्षमता को GetValuesForInput-type विधि के माध्यम से उजागर किया जाता है , और कार्यान्वयन में मेरा भारी कथन छिपा हुआ है।

— ब्रायन बोएचर

Answer 6

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

Answer 7

मुझे लगता है कि यहाँ प्रमुख शब्द 'शायद ही' है

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

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

Comments

यह इस बात पर निर्भर करता है कि संकलक कितना अच्छा है। डेल्फी में एक केस स्टेटमेंट बेहद कुशल हो सकता है।

— लोरेन Pechtel

Answer 8

यदि आप अपने एप्लिकेशन में बड़ी मात्रा में डेटा संग्रहीत करते हैं, तो आपका प्रोग्राम धीमी गति से लोड हो सकता है और यदि कोई बायनेरिज़ या निष्पादन योग्य के साथ खेल सकता है तो आप कोड को जोखिम में डाल सकते हैं।

इसके अलावा, यदि प्रोग्राम को कई बार संपादित किया जाता है, जो जानता है, तो हो सकता है कि आप गलती से या गलत कमांड के परिणामस्वरूप किसी संख्या को गलत तरीके से बता सकते हैं।

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

डेटा और कोड को अलग करना एक अच्छा अभ्यास है विशेष रूप से यदि डेटा बड़ा है।