कोर डाटा बनाम NSFileManager

Question

समस्या:

मैं कुछ समय के लिए अब अपने ही कैश प्रणाली NSFileManager का उपयोग करके उपयोग किया गया है। आम तौर पर मुझे प्राप्त डेटा JSON है और मैं सिर्फ शब्दकोश को सीधे कैश में (दस्तावेज़ फ़ोल्डर में) सहेजता हूं। जब मुझे इसकी आवश्यकता होती है तो मैं इसे प्राप्त कर दूंगा। मैं भी लागू करता हूं, कभी-कभी जब मुझे लगता है कि यह बेहतर है, तो NSDictionary रूट फ़ोल्डर पर किसी दिए गए संसाधन के पथ के लिए कुंजी/मानों के साथ। उदाहरण के लिए:

जेनेव में मौसम के बारे में संसाधन 17/02/2013, इसलिए मेरे पास GE_17_02_2013 नामक एक कुंजी होगी और NSDictionary के लिए जानकारी के साथ मूल्य का मूल्य होगा।

आम तौर पर मुझे कोई जटिल प्रश्न करने की आवश्यकता नहीं है। लेकिन, किसी भी तरह, और जो मैं पढ़ रहा हूं, जब आपके पास बहुत अधिक डेटा है, तो आपको कोर डेटा के साथ रहना चाहिए। मेरे मामले में, मेरे पास आमतौर पर बहुत अधिक डेटा होता है, लेकिन मुझे वास्तव में कभी भी एप्लिकेशन को नीचे जाने या प्रदर्शन के संदर्भ में पीड़ित महसूस नहीं हुआ। तो मेरी प्रश्न हैं:

1. इस मामले में, जहां कभी कभी (मौसम बात सिर्फ एक उदाहरण था) मैं तो बस (एक ट्विटर फ़ीड, उदाहरण के लिए) सभी डेटा को हटाने और एक द्वारा यह प्रतिस्थापित करना होगा डेटा की पूरी तरह से नई धारा, कोर डेटा मूल्य है? मुझे लगता है कि सभी डेटा को हटाकर, (पॉपुलटिंग) डालना, NSDictionary को स्टोर करने और पुराने को बदलने की तुलना में भारी है।

2. कभी कभी यह छवियों, textfiles, आदि envolve हैं और NSFileManager यह पूरी तरह से करता है, तो क्या फायदे कोर डाटा इस मामलों में ला सकता है?

पी.एस: मैं सिर्फ this पोस्ट, जहां सवाल इस तरह का बना है और संख्या एक वास्तव में तेजी से होता है जो साबित देखा। फिर भी, मैं एक अनुभवजन्य उत्तर भी पसंद करूंगा।

Answer 1

कोर डेटा आपके द्वारा वर्णित हर परिदृश्य में उपयोग करने योग्य है। वास्तव में, यदि कोई ऐप वरीयताओं से अधिक स्टोर करता है, तो आपको शायद कोर डेटा का उपयोग करना चाहिए।

• निश्चित रूप से फाइल सिस्टम की तुलना में तेजी है, भले ही आप सब कुछ का सफाया और इसे फिर से लिखने के रूप में आप का वर्णन (ताकि आप नहीं है: यहाँ कुछ कारण, जो बीच में, आप अपने खुद समस्याओं लिए जवाब मिल जाएगा रहे हैं कैशिंग से ज्यादा लाभ)। यह मूल रूप से है क्योंकि आप अपने परिचालनों को जोड़ सकते हैं और आवश्यकता होने पर ही स्टोर तक पहुंच सकते हैं। तो यदि आप पढ़ते हैं, लिखते हैं और पढ़ते हैं, तो आप केवल एक बार बचा सकते हैं, शेष स्मृति में किया जाता है, जो कहने की जरूरत नहीं है, बहुत तेज है।
• सबकुछ संस्करणित है और आप आसानी से एक संस्करण से दूसरे में माइग्रेट कर सकते हैं (उपयोगकर्ता को डिवाइस पर मौजूद सामग्री को रखते हुए)
• आपके मॉडल ऑपरेशंस का 80% निःशुल्क आते हैं। जैसे, जब कुछ बदलता है, तो आप willSave प्रबंधित ऑब्जेक्ट विधि को ओवरराइड कर सकते हैं और अपने नियंत्रकों को सूचित कर सकते हैं।
• cascade का उपयोग कर इसे तुच्छ भी बहुत जटिल वस्तु संरचनाओं को हटाने के लिए
• जबकि एक बुरा विचार डेटाबेस में छवियों को रखने के लिए है, तो आप अभी भी उन्हें फाइल सिस्टम पर रखने के लिए और जब प्रबंधित वस्तु कोर डेटा उन्हें स्वचालित रूप से हटाना हो सकता है कि बनाता है उनका प्रतिनिधित्व करता है
• लचीला है, वास्तव में इतना लचीला है कि आप एक कस्टम डेटा स्टोर लिखकर बहुत कम संशोधन वाले सर्वर का उपयोग करने के लिए स्थानीय फाइल सिस्टम का उपयोग करने से अपने प्रोजेक्ट को माइग्रेट कर सकते हैं।
• कोर डेटा डिजाइनर मूल रूप से आपके लिए मॉडल ऑब्जेक्ट बनाता है। आप

Answer 2

(यदि फ़ाइल सिस्टम का उपयोग आप करना होगा जो) इस मामले में अपने स्वयं के मॉडल कक्षाएं बनाने के लिए की जरूरत नहीं है ... कोर डाटा इसके लायक है?

हां, इस सीमा तक कि आपको अपनी फ़ाइल-सिस्टम स्कीमा तैयार करने की कोशिश करने से कुछ अधिक केंद्रीय रूप से प्रबंधित करने की आवश्यकता है। कोर डेटा, और इसके निचले स्तर के चचेरे भाई एसक्यूएल, अभी भी दृढ़ता के लिए सबसे अच्छा विकल्प हैं जो हमारे पास अभी है। इसके अलावा, एक शब्दकोश को क्रमबद्ध/deserializing रखने के लिए NSKeyed(Un)Archiver का उपयोग करने का प्रदर्शन हिट बार-बार बड़े डेटासेट के साथ तेजी से ध्यान देने योग्य हो जाता है।

मैं सारा डेटा भी हटा, और (पॉप्युलेट) डालने यह, भारी से सिर्फ NSDictionary की दुकान है और पुराने एक की जगह लगता है।

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

कभी कभी यह छवियों, textfiles, आदि envolve हैं और NSFileManager यह पूरी तरह से करता है, तो क्या फायदे कोर डाटा इस मामलों में ला सकता है?

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