आईफोन और कोर डेटा: अपडेट के बीच उपयोगकर्ता द्वारा दर्ज डेटा को कैसे बनाए रखें?

Question

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

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

लेकिन, अब मुश्किल हिस्सा: हम कैसे (गतिशील) उपयोगकर्ता कस्टम डेटा को ध्वनि तरीके से संग्रहीत करते हैं?

मेरा पहला विचार यह है कि (गतिशील) डेटाबेस को ऐप के लिए दस्तावेज़ निर्देशिका में संग्रहीत किया जाना चाहिए, इसलिए एप्लिकेशन अपडेट मौजूदा डेटा को बंद नहीं करते हैं। क्या मैं सही हूँ?

मेरा दूसरा विचार यह है कि चूंकि (गतिशील) उपयोगकर्ता कस्टम डेटा डेटाबेस (स्थिर) पशु कैटलॉग के समान स्टोर में नहीं है, इसलिए हम रेटिंग और नोट्स इकाइयों के बीच एक रिश्ता बना सकते हैं (एक में डेटाबेस) और पशु इकाई (अन्य डेटाबेस में)। इस मामले में, मुझे लगता है कि एक समाधान रेटिंग/नोट्स इकाई में "animalName" स्ट्रिंग प्रॉपर्टी होगा, और इसे रनटाइम पर मिलान करें। क्या यह करने का सबसे अच्छा तरीका है, या कोर डेटा में दो अलग-अलग डेटाबेस "सिंक" करने का कोई तरीका है?

Answer 1

मूल रूप से मैं इसे कैसे हल कर रहा हूं।

जबकि अमोरिया और मेहरिसन के जवाब मान्य थे, उनके पास एक धारणा थी: एक बार बनाया गया था, न केवल टेबल बल्कि प्रत्येक तालिका में प्रत्येक पंक्ति हमेशा एक जैसी होगी।

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

इस समस्या से बचने का एकमात्र तरीका केवल एक बार डेटाबेस को पूर्व-पॉप्युलेट करने की आवश्यकता होगी, और फिर प्रत्येक बार अद्यतन होने पर पंक्तियों को मैन्युअल रूप से अपडेट करना होगा। हालांकि, इस तरह की प्रक्रिया मेरे मामले में वास्तव में संभव नहीं है।

तो, समाधान क्या है? खैर, क्योंकि मैं कोर डेटा बनाता है कि विदेशी कुंजी संबंधों पर भरोसा नहीं कर सकता, मुझे अपना खुद का बनाना है। मैं जो करता हूं वह मेरी डेटाबेस पीढ़ी की प्रक्रिया में एक मध्यवर्ती कदम पेश करता है: मेरा कच्चा डेटा लेने के बजाय (जो यूटीएफ -8 पाठ होता है लेकिन वास्तव में एमएस वर्ड फाइल होता है) और सीधे कोर डेटा के साथ SQLite डेटाबेस बनाना, मैं मध्यस्थ को पेश करता हूं चरण: मैं .txt से .xml में कनवर्ट करता हूं। एक्सएमएल क्यों? खैर, ऐसा नहीं है क्योंकि यह एक चांदी की बुलेट है, लेकिन सिर्फ इसलिए कि यह एक डेटा प्रारूप है, मैं बहुत आसानी से पार्स कर सकता हूं। तो यह एक्सएमएल फ़ाइल अलग क्या है? एक हैश मान जो मैं प्रत्येक पशु के लिए एमडी 5 का उपयोग कर उत्पन्न करता हूं, जिसे मैं मानता हूं वह अद्वितीय है। के लिए हैश मूल्य क्या है? खैर, अब मैं दो डेटाबेस बना सकता हूं: एक "स्थैतिक" पशु डेटा (जिसके लिए मेरे पास पहले से ही एक प्रक्रिया है), और "गतिशील" रेटिंग डेटाबेस के लिए एक, जिसे आईफोन ऐप बनाता है और जो एप्लिकेशन की दस्तावेज़ निर्देशिका में रहता है । प्रत्येक रेटिंग के लिए, मैं पशु इकाई के हैश मूल्य को बचाकर पशु के साथ एक छद्म संबंध बना देता हूं। इसलिए जब भी उपयोगकर्ता आईफोन पर एक पशु विवरण दृश्य लाता है, तो मैं "गतिशील" डेटाबेस से पूछता हूं कि क्या रेटिंग इकाई मौजूद है जो Animal.md5Hash मान से मेल खाती है।

चूंकि मैं इस इंटरमीडिएट एक्सएमएल डेटा फ़ाइल को सहेज रहा हूं, अगली बार एक अपडेट है, मैं इसे अंतिम एक्सएमएल फाइल के खिलाफ अलग कर सकता हूं जो मैंने देखा है कि क्या बदल गया है। अब, अगर जानवर का नाम बदल दिया गया था - मान लीजिए कि एक टाइपो सही किया गया था - मैं उस जानवर के लिए हैश मान को सीटू में वापस लाता हूं। इसका मतलब है कि यहां तक ​​कि यदि कोई पशु नाम बदल दिया गया है, तो भी "गतिशील" डेटाबेस में, यदि यह मौजूद है, तो भी मैं मिलान करने वाली रेटिंग ढूंढ पाऊंगा।

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

Answer 2

जिस तरह से मैं यह कर रहा हूं वह है: अपने ऐप बंडल के हिस्से के रूप में स्थिर सामग्री का डेटाबेस भेज दें। ऐप लॉन्च पर, जांचें कि दस्तावेजों में डेटाबेस फ़ाइल है या नहीं। यदि नहीं, तो ऐप बंडल से दस्तावेज़ों में से एक को कॉपी करें। फिर दस्तावेज़ों से डेटाबेस खोलें: यह केवल वही है जिसे आप पढ़ते हैं और संपादित करते हैं।

जब कोई अपग्रेड हुआ, तो नई स्थैतिक सामग्री को उपयोगकर्ता के संपादन योग्य डेटाबेस के साथ विलय करने की आवश्यकता होगी। प्रत्येक स्थैतिक वस्तु (पशु, आपके मामले में) में फैक्ट्रीआईडी ​​नामक एक फ़ील्ड होता है, जो एक अद्वितीय पहचानकर्ता होता है। अद्यतन के बाद पहले लॉन्च पर, ऐप बंडल से डेटाबेस लोड करें, और प्रत्येक पशु के माध्यम से पुनरावृत्त करें। प्रत्येक के लिए, कार्य डेटाबेस में उचित रिकॉर्ड पाएं, और आवश्यकतानुसार किसी भी फ़ील्ड को अपडेट करें।

एक त्वरित समाधान हो सकता है, लेकिन अपग्रेड प्रक्रिया अक्सर नहीं होती है, इसलिए लिया गया समय बहुत ही समस्याग्रस्त नहीं होना चाहिए।

Answer 3

दस्तावेज़ निर्देशिका (NSDocumentDirectory) में अपने SQLite डेटाबेस को संग्रहीत करना निश्चित रूप से जाने का तरीका है। सामान्य रूप से, आपको एप्लिकेशन परिवर्तनों से बचना चाहिए जो जितना संभव हो सके SQL तालिकाओं को संशोधित या हटाएं (जोड़ना ठीक है)। हालांकि, जब आपको बिल्कुल अद्यतन में बदलाव करना पड़ता है, तो अमोरिया ने जो कुछ कहा वह काम करेगा - पुराने डीबी को खोलें, जो भी आपको नए डीबी में चाहिए, आयात करें और पुराने को हटा दें।

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